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? If not we should do
this.
As for moving code from a package to another, we could have a little
temporary duplication of code by having the same methods in two
different packages.

> - How to manage fixes that go across multiple packages?

Package mantainers will have to coordinate for this, each applying the
fixes to his package(s).

> - What to do with essential packages that do not have a maintainer?
> Kernel, Collection, ...

We should find a mantainer for those.

> - What to do with essential packages that have a maintainer but that
> do not get maintained? No insults, therefor no examples ...

This depends on circumstances. In the best case, we should be able to
find a substitute mantainer. In the worst case, we would be forced to
fork (I don't like the idea, but sometimes it's necessary). Witness what
happened with XFree86 in the Linux world: XFree86's core team became
constantly unresponsive to external inputs, until someone decided to
fork the code and create the X.org server, which was adopted by almost
all distros.

	Giovanni