A process proposal for 3.10

Philippe Marschall philippe.marschall at gmail.com
Mon Oct 16 11:16:07 UTC 2006


2006/10/16, Giovanni Corriga <giovanni at corriga.net>:
> Il giorno lun, 16/10/2006 alle 12.50 +0200, Philippe Marschall ha
> scritto:
> > 2006/10/16, Giovanni Corriga <giovanni at corriga.net>:
> > > Il giorno lun, 16/10/2006 alle 10.55 +0200, Lukas Renggli ha scritto:
> > > > > This proposal is based on two points:
> > > > > - decentralization of development
> > > > > - fixed duration of iterations ("timeboxing")
> > > >
> > > > Sounds like a good proposal, however I see a couple of problems that
> > > > you don't adress:
> > > >
> > > > - How to manage the code and the changes? Most changes related to
> > > > Compiler, CompiledMethod, Behavior, Traits, etc. cannot be loaded
> > > > using Monticello.
> > >
> > > How did these things get managed in 3.9? By changeset and DoIts? Will it
> > > be possible to keep doing this for 3.10, until we develop better tools?
> > > (MC2 maybe?)
> > > On the other hand, I know this was pretty ugly for Marcus and Stef.
> > > Would reducing the scope of the changes to manageable bites solve this,
> > > at least in part?
> > >
> > > > - What to do with code that is not properly packaged yet? How to pass
> > > > code over to another package?
> > >
> > > Isn't all code in the image segmented into packages?
> >
> > In theory yes. In praxis no. You can't just go there and unload eToys.
>
> if we want eToys to be maintained, then the first task of the eToys team
> will be to make eToys unloadable.

And if they don't?

> If we don't find anyone for maintaining eToys, we delete them from the
> system, without worring if they were packaged or not.

This will break the system.

> > > If not we should do  this.
> >
> > Sure, but it's not a simple task. Do you volunteer?
>
> I would if I had time, but I have a graduation to prepare.
>
> > > > - What to do with essential packages that do not have a maintainer?
> > > > Kernel, Collection, ...
> > >
> > > We should find a mantainer for those.
> >
> > And if we don't find one. Drop Kernel? Somewho doesn't like a realistic threat.
>
> I think it will be unlikely not to find anyone for Kernel and/or
> Collection mantainance.

Whom?

> The alternative would be keeping them in the image, but letting them
> rot.

You see writing mails full of "we should" is always easy. But when it
comes down to doing stuff,....

Philippe



More information about the Squeak-dev mailing list