A process proposal for 3.10
stephane.ducasse at gmail.com
Mon Oct 16 21:22:19 UTC 2006
I like the process you describe but we have to consider time and
>> - 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
Been in package does not mean that you can manage it.
We got problems with MC sometimes.
> 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.
This is not a question of duplication this is a question of slices
been done at the ***same time***
>> - 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).
Look at the fix andreas proposed for TTC he will not include in Graphics
because he is not the owne of multilangual.
I think that the solution is simple:
- the release team tries to minimize changes to packages it does not
as much as possible but not less.
On certain occasion it publishes/changes maintained package and the
can react and we can roll back.
>> - What to do with essential packages that do not have a maintainer?
>> Kernel, Collection, ...
> We should find a mantainer for those.
The granularity of the packages can kill us.
>> - 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
> 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.
More information about the Squeak-dev