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 not we should do  this.

Sure, but it's not a simple task. Do you volunteer?

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

And if we don't find one. Drop Kernel? Somewho doesn't like a realistic threat.

Philippe

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