[etoys-dev] together again

Andreas Raab andreas.raab at gmx.de
Mon Oct 5 23:58:53 EDT 2009

Jecel Assumpcao Jr wrote:
> Göran Krampe wrote:
>> I agree that it may be premature, but since the discussion was brought 
>> up I wanted to make it clear that some of us out here don't consider 
>> ourselves "eToys haters" *nor* do we want an intertangled base.
> Indeed. I think it is good to have these discussions now. I will start
> by confessing that I have not looked at the Etoys code to see what the
> problem is, so am only repeating what other people have said.

Actually, this is *precisely* why I'm saying it's premature to talk 
about these issues. Neither you, nor Göran, nor Serge, nor I have really 
any clue about what it entails. Consequently we are only discussing our 
own prejudices about Etoys.

If we want to move this forward we need insights from the Etoys 
developers. We need someone who can take a high-level census of Etoys 
and tell us which areas are mostly unchanged, which areas have undergone 
significant changes, which areas need to be closely investigated.

 From a practical perspective, one way to move forward would be 
something along the following lines:

* Get MC loaded into the Etoys image (by hook or by crook)
* Create the package structure we find in the trunk
* Adopt the latest trunk versions as ancestors (to fake heritage)
* FixUnderscores where necessary
* Compute the number of changes between the Etoys image and trunk

Once finished, I think we will find that packages generally fall into 
one of the following categories:

* New: Packages that are in one but not the other
* Easy: Less than 100 changes between versions
* Hard: Less than 1000 changes between versions
* Ouch: More than 1000 changes between versions

Based on this we should be able to get a feel for what we're talking 
about on the highest level. I'm in particular interested in packages 
that are in one but not the other since they are most likely the ones 
that create the most unforeseen dependencies (take traits for example or 
pango rendering).

   - Andreas

More information about the etoys-dev mailing list