| 1 |
On Monday 02 February 2004 10:27, Brian Jackson wrote: |
| 2 |
> One problem I have with this is that it says all ebuilds should remain in |
| 3 |
> the tree for a minimum of one year. 4 releases a year, and every package in |
| 4 |
> the tree is going to have 4 versions that can't be cleaned out for at least |
| 5 |
> a year. Not to mention that it's going to be hard to get developers in to |
| 6 |
> the mindset of saving old ebuilds when we've been beating them ruthlessly |
| 7 |
> about keeping portage clean for the past 6 months at least. Do you have any |
| 8 |
> ideas about how to deal with this? |
| 9 |
Hm, as I read it its supposed to be a separate tree or at least a branch. As |
| 10 |
such the ebuilds only go in at the releases and then stay there. The real |
| 11 |
problems would be |
| 12 |
1. backporting the necessary fixes to the old versions |
| 13 |
2. Actually cleaning up stale ebuilds. But this one can be automated rather |
| 14 |
trivially and is only a marginal problem if automation is undesirable.. |
| 15 |
|
| 16 |
However the 1st one is genuine (as I would expect the backporting policy to be |
| 17 |
essential for a server project), but it may be a part of a "premium" services |
| 18 |
(along with 1yr -> 3yr extension) if we ever go around that. |
| 19 |
|
| 20 |
George |
| 21 |
|
| 22 |
|
| 23 |
-- |
| 24 |
gentoo-dev@g.o mailing list |
Archives