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
On 6/12/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
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.
Why is duplicate code a concern? Monticello's designed to have any number of copies of the same package version floating around; they preserve their identity. So there's only duplication in the sense that there's storage space used in two repositories, which hardly seems like a big deal.
Avi
packages@lists.squeakfoundation.org