iSqueak
stéphane ducasse
ducasse at iam.unibe.ch
Sun Jun 12 07:45:27 UTC 2005
>
> 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
More information about the Packages
mailing list