| 1 |
On Mon, 2004-02-02 at 13:27, Brian Jackson wrote: |
| 2 |
> One problem I have with this is that it says all ebuilds should remain |
| 3 |
in the |
| 4 |
> tree for a minimum of one year. 4 releases a year, and every package |
| 5 |
in the |
| 6 |
> tree is going to have 4 versions that can't be cleaned out for at |
| 7 |
least a |
| 8 |
> year. Not to mention that it's going to be hard to get developers in |
| 9 |
to the |
| 10 |
> mindset of saving old ebuilds when we've been beating them ruthlessly |
| 11 |
about |
| 12 |
> keeping portage clean for the past 6 months at least. Do you have any |
| 13 |
ideas |
| 14 |
> about how to deal with this? |
| 15 |
|
| 16 |
One option would be to take a modified version of the approach that |
| 17 |
OpenBSD uses: X times per year a "release" is made by a script that |
| 18 |
looks through the tree for stable-marked ebuilds and tags them |
| 19 |
RELEASE-YYYY_N and either creates a new STABLE-YYYY_N branch or adds the |
| 20 |
ebuilds to an already-existing STABLE branch (my personal preference |
| 21 |
would be for the former, but that may be just because I'm more familiar |
| 22 |
with it). By adding bugfixes to the appropriate STABLE branch we |
| 23 |
rigorously enforce the difference between a static release and the |
| 24 |
slowly-moving stable branch. Moreover, once the release has been cut it |
| 25 |
shouldn't matter if devs prune the HEAD tree, since the old ebuilds will |
| 26 |
still be in the appropriate branch as far as the users are concerned. |
| 27 |
|
| 28 |
Incidentally, I agree w/ Spider. I think that four Enterprise releases |
| 29 |
per year is overly ambitious. |
| 30 |
|
| 31 |
Best, |
| 32 |
g2boojum |
| 33 |
-- |
| 34 |
Grant Goodyear <g2boojum@g.o> |
Archives