| 1 |
On Mon, Feb 02, 2004 at 12:27:08PM -0600 or thereabouts, Brian Jackson wrote: |
| 2 |
> One problem I have with this is that it says all ebuilds should remain in the |
| 3 |
> tree for a minimum of one year. 4 releases a year, and every package in the |
| 4 |
> tree is going to have 4 versions that can't be cleaned out for at least a |
| 5 |
> year. Not to mention that it's going to be hard to get developers in to the |
| 6 |
> mindset of saving old ebuilds when we've been beating them ruthlessly about |
| 7 |
> keeping portage clean for the past 6 months at least. Do you have any ideas |
| 8 |
> about how to deal with this? |
| 9 |
|
| 10 |
Valid point. One suggestion I would have would be to add a "date created" |
| 11 |
stamp to each ebuild (or perhaps this information is already there in the |
| 12 |
header somewhere). Then, we can track that info across the whole stable |
| 13 |
tree so the developer wouldn't have to worry about it. |
| 14 |
|
| 15 |
That is to say that, once it makes it into the stable tree, the developer |
| 16 |
isn't responsible for ensuring it stays there for a year -- it's up to the |
| 17 |
maintainers of the stable tree (gentoo-server unless releng wants the job). |
| 18 |
|
| 19 |
I also like this solution because it would allow us to do useful things |
| 20 |
like publish a schedule of when various ebuilds will be retired so users |
| 21 |
can check them ahead of time and plan accordingly. |
| 22 |
|
| 23 |
--kurt |
Archives