Kind of postmortem analysis for 3.9

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Kind of postmortem analysis for 3.9

Stéphane Ducasse-3
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



Reply | Threaded
Open this post in threaded view
|

Re: Kind of postmortem analysis for 3.9

Pavel Krivanek
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 and if it will be possible to define package
that contains code of several next packages, it will be possible to
create MC package for the RestOfSqueak of my kernel image

-- 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
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Kind of postmortem analysis for 3.9

Philippe Marschall
In reply to this post by Stéphane Ducasse-3
2006/10/9, Stéphane Ducasse <[hidden email]>:

> 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.

MCC?

Philippe

Reply | Threaded
Open this post in threaded view
|

Re: Kind of postmortem analysis for 3.9

Philippe Marschall
In reply to this post by Pavel Krivanek
2006/10/9, Pavel Krivanek <[hidden email]>:

> 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

I think the PackageInfo of Impara supports preambles and postscripts
together with Moniticello.

Philippe

>
> -- 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
> >
> >
> >
> >
>
>