iSqueak

[stéphane ducasse]

>
> Actually, instead of having "approval flags" I'd recommend having  
> "release repositories". E.g., consider that we're setting up a 3.9  
> repository which defines the "latest" package versions for  
> everything that ought to be in 3.9.
>
> Rather than "approving" a package version in their own repository,  
> a maintainer (or release master) would publish (or copy) package  
> versions to the release repository. This has a number of extra  
> advantages - fixes that turn out to be important for a release can  
> be put into this repository but may never appear in the "master"  
> repository for the package (because it might have been a last- 
> minute workaround). Integration fixes can be done for the release  
> and then fed back to the package owners.
>
> Basically, you're defining your own package environment, treating  
> the repository as a distribution and decide when you want to update  
> the distribution from the latest package versions developed by the  
> owner of the package.

Don't think that this will be a bit difficult to manage after a while.
By the I did not have the time to look at the isqueak image but I  
read the tweak faq and I have a question:
do you only load package from a single source?
Because I thought that it would be good to be able to load YAXO and  
MC from their home source to avoid
duplicate code.

>> The initial maintainership model could err on the side of openness,
>> maybe even having some people with write access to all packages.   
>> Then
>> we could restrict it a bit more later.
>>
>
> With the above model you could restrict commit rights for the  
> release repository to the people actually working on the release,  
> whereas access to the "master" repository is limited to whatever  
> the package owner decides. This seems like a good model to me  
> because it leaves the responsibilities in the right places.

My main question is if we have enough man power for that.

Stef