| 1 |
> 1) A more robust QA process for the main portage tree or |
| 2 |
> 2) A seperate 'server' portage tree that offered: |
| 3 |
> * only updated quarterly |
| 4 |
> * security and major bug-fixes off-cycle, but no other changes to the |
| 5 |
> tree |
| 6 |
> * guaranteed minimum life of all ebuilds in the tree |
| 7 |
> |
| 8 |
|
| 9 |
My vote is for #2. I think it would be the easiest to implement, and |
| 10 |
my guess is the servers wouldn't mind another portage tree. It's the |
| 11 |
distfiles that take up all the space. |
| 12 |
|
| 13 |
But if the server group could maintain a 'stable' or 'enterprise' tree |
| 14 |
I think it would go a *long* way. I currently do this on my own |
| 15 |
internally at my company, but it *sucks* because I dont' have the time |
| 16 |
to track all the changes and what not. Pooling the collective efforts |
| 17 |
of everyone else is a Good Thing(tm). |
Archives