A process proposal for 3.10

stephane ducasse 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  
energy too.

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

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

More information about the Squeak-dev mailing list