On Mon, 2004-02-02 at 13:27, Brian Jackson wrote: > One problem I have with this is that it says all ebuilds should remain in the > tree for a minimum of one year. 4 releases a year, and every package in the > tree is going to have 4 versions that can't be cleaned out for at least a > year. Not to mention that it's going to be hard to get developers in to the > mindset of saving old ebuilds when we've been beating them ruthlessly about > keeping portage clean for the past 6 months at least. Do you have any ideas > about how to deal with this?
One option would be to take a modified version of the approach that OpenBSD uses: X times per year a "release" is made by a script that looks through the tree for stable-marked ebuilds and tags them RELEASE-YYYY_N and either creates a new STABLE-YYYY_N branch or adds the ebuilds to an already-existing STABLE branch (my personal preference would be for the former, but that may be just because I'm more familiar with it). By adding bugfixes to the appropriate STABLE branch we rigorously enforce the difference between a static release and the slowly-moving stable branch. Moreover, once the release has been cut it shouldn't matter if devs prune the HEAD tree, since the old ebuilds will still be in the appropriate branch as far as the users are concerned. Incidentally, I agree w/ Spider. I think that four Enterprise releases per year is overly ambitious. Best, g2boojum -- Grant Goodyear <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
