A process proposal for 3.10

Giovanni Corriga giovanni at corriga.net
Mon Oct 16 12:33:26 UTC 2006


Il giorno lun, 16/10/2006 alle 13.16 +0200, Philippe Marschall ha
scritto:
> 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.

Will it? Then we'll have to fix the breakage. This can be done, for
example by moving methods to other packages and slimming down eToys
before removing. This may also mean that we would have to plan removal
of eToys on a larger timeframe (a part in 3.10, then some more in 3.11,
then the rest later).

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

I don't know now. But why do you think that some won't volunteer, if we
decide to go this route?

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

That's why this is a proposal. Let's discuss it as we're doing, decide
if we want to adopt it, and see were this leads us.

So, aside from these points, what do you think?

	Giovanni




More information about the Squeak-dev mailing list