Kind of postmortem analysis for 3.9

> May be this email did not show up, so I resent it
>
> Hi
>
> Here are some thoughts about the problems we got with 3.9.
>
> - MC misses the notion of slices (groups of packages version together).
> When introducing a changes touching different packages we need to
> identify the changes as a
> slice of brotherhood of packages.
>         -- would be good for slices identification but also to be able to
> load a given version or tag it.
>         - - seems that MC2 is going in that direction.
>
> We need the ability to define a certain state (that consists of
> multiple packages all with a certain version)
> as one overall version. Like we would do in CVS with taging.
>
> Then, related but different: patches are cross-cutting. That's what
> nice with a .cs: "This is the fix of bug X". Applying
> the fix will change set version of the package, but we don't want to
> loose the information that all these changes are
> one thing.
>
> Right now we have no way of expressing that with MC, changesets did
> that quite well.
>
> - Moving methods between packages is difficult. We LOST a LOT of time
> there. In particular the way class extension is encoded in string of
> category is a pain. Since we can load a cs which can contain a
> category reorganization and we could lose simply the package
> extensions. So there is a real clash of way of managing the code.
>
> - In general, we need package refactorings.. splitting, joining,
> moving stuff between them.
>
> - having an load and unload actions protocols would be nice.
>
> - atomic loading is really needed. Apparently SystemEditor (funny
> name, aka atomic loader) is doing that. So this should be really
> investigated. We lost a LOT of energy/time there.
>
> - We should invest in better tests and a test server.
> Not only a test server, but an integration server: Building up a
> bigger image from a  smaller one, then runs
> all the tests.
>
> - Package decomposition and responsibility started to work.
>
> - SqueakMap should be improved to avoid all the problems with the
> data corruption.
>
> - Took too much time. Would be good to have a 6 months release cycle
>
> - Should have given name to source = 39a, 39b....
>
> - Good idea to have release candidates
>
> - We should have removed packages (nebraska and other much earlier)
> We got trapped at the end with that.
>
> Stef and Marcus
>
>
>
>

> May be this email did not show up, so I resent it
>
> Hi
>
> Here are some thoughts about the problems we got with 3.9.
>
> - MC misses the notion of slices (groups of packages version together).
> When introducing a changes touching different packages we need to
> identify the changes as a
> slice of brotherhood of packages.
>         -- would be good for slices identification but also to be able to
> load a given version or tag it.
>         - - seems that MC2 is going in that direction.
>
> We need the ability to define a certain state (that consists of
> multiple packages all with a certain version)
> as one overall version. Like we would do in CVS with taging.

> Some next MC comments:
>
> - the classes initialization part must be optional
> - the classes must be initialized in the right order. When I was
> preparing the MC packages for my kernel image, I saw that sometimes
> the inherited class is initialized before the parent class. If the
> derived class needs for example some parent constants during class
> initialization, it may fail.
> - there must be possible to create class definition change. For
> example if some package adds an instance variable (and some next
> methods) to a class that is not part of the package
> - as far as I remember it was not possible to create a package that
> contained only new method extension for a trait
>
> If this will be solved, if packages will include package
> initialization scripts

>
> -- Pavel
>
> On 10/9/06, Stéphane Ducasse <[hidden email]> wrote:
> > May be this email did not show up, so I resent it
> >
> > Hi
> >
> > Here are some thoughts about the problems we got with 3.9.
> >
> > - MC misses the notion of slices (groups of packages version together).
> > When introducing a changes touching different packages we need to
> > identify the changes as a
> > slice of brotherhood of packages.
> >         -- would be good for slices identification but also to be able to
> > load a given version or tag it.
> >         - - seems that MC2 is going in that direction.
> >
> > We need the ability to define a certain state (that consists of
> > multiple packages all with a certain version)
> > as one overall version. Like we would do in CVS with taging.
> >
> > Then, related but different: patches are cross-cutting. That's what
> > nice with a .cs: "This is the fix of bug X". Applying
> > the fix will change set version of the package, but we don't want to
> > loose the information that all these changes are
> > one thing.
> >
> > Right now we have no way of expressing that with MC, changesets did
> > that quite well.
> >
> > - Moving methods between packages is difficult. We LOST a LOT of time
> > there. In particular the way class extension is encoded in string of
> > category is a pain. Since we can load a cs which can contain a
> > category reorganization and we could lose simply the package
> > extensions. So there is a real clash of way of managing the code.
> >
> > - In general, we need package refactorings.. splitting, joining,
> > moving stuff between them.
> >
> > - having an load and unload actions protocols would be nice.
> >
> > - atomic loading is really needed. Apparently SystemEditor (funny
> > name, aka atomic loader) is doing that. So this should be really
> > investigated. We lost a LOT of energy/time there.
> >
> > - We should invest in better tests and a test server.
> > Not only a test server, but an integration server: Building up a
> > bigger image from a  smaller one, then runs
> > all the tests.
> >
> > - Package decomposition and responsibility started to work.
> >
> > - SqueakMap should be improved to avoid all the problems with the
> > data corruption.
> >
> > - Took too much time. Would be good to have a 6 months release cycle
> >
> > - Should have given name to source = 39a, 39b....
> >
> > - Good idea to have release candidates
> >
> > - We should have removed packages (nebraska and other much earlier)
> > We got trapped at the end with that.
> >
> > Stef and Marcus
> >
> >
> >
> >
>
>