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.
If we don't find anyone for maintaining eToys, we delete them from the
system, without worring if they were packaged or not.

> > 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.
The alternative would be keeping them in the image, but letting them
rot.

	Giovanni