[etoys-dev] Re: Need for translation in DrGeo

[Andreas Raab]

On 5/17/2010 11:42 PM, Hilaire Fernandes wrote:
> Sure I will propose improved version of DrGeoII for Etoys.
> One important note: if people should commit improvment to DrGeo they
> should do it in the primary DrGeo package. I do not have the ressource
> to look at DrGeo improvment in two different places.
> So the published DrGeoII package in etoysInbox should be readonly. In
> fact I am pretty sure it is not a good idea I publish DrGeoII in
> EtoysInbox, I am pretty sure people will publish changed there.
> Hum, need a few though on that...

Yes, please think about it. One thing to realize is that when you want 
your package included in someone's image you are giving up some control 
over it. There is no way to change that. Requiring the package to be 
treated 'read-only' is not feasible. It's a lesson I learned years back 
when I tried to maintain the Graphics and some other packages across 
Squeak and Croquet and had just the same view on how all changes should 
be done upstream.

The short version is: It doesn't work. When someone makes a fix they 
*will* commit it to the inbox because that's the place where fixes go. 
And keeping lists of external repositories up to date isn't going to 
work either, largely just because of reliability issues - what happens 
when Squeaksource is down again? Lots and lots of issues that way and 
I've learned since then that by adding your package to some image you 
need to enter a more flexible relationship.

Really, the way think about it is this: You release a version of the 
package(s) for that image version. It's up to those people to take it 
from there and make adjustments as required. When you see fit (i.e., 
when you have the time) you check on things to see if there have been 
any modifications that should be merged upstream. If not, let the 
downstream know when there is a new package version and let them merge 
it. Unless there are major differences, this approach allows everyone to 
get their work done - you can concentrate on functionality improvements, 
the downstream can do the maintenance that's required.

Cheers,
   - Andreas