| 1 |
On 21/02/2011 00:11, Enrico Weigelt wrote: |
| 2 |
> * Markos Chandras<hwoarang@g.o> schrieb: |
| 3 |
> |
| 4 |
>> My suggestion, as I said to fosdem, is to freeze, or take a |
| 5 |
>> snapshot if you like, of the current tree, stabilize what you |
| 6 |
>> need to stabilize, test the whole tree ( at least compile wise ) |
| 7 |
>> for a couple of weeks and then replace the existing stable tree. |
| 8 |
> hmm, would it make sense to add a new masking for the testing |
| 9 |
> tree, so users could decide which stability grade vs they wish ? |
| 10 |
> or perhaps use overlays for that ? |
| 11 |
> |
| 12 |
> For example, I'd like to have the critical packages (everything |
| 13 |
> that's needed to bootup and do basic remote maintenance) from |
| 14 |
> the new frozen-stable tree, but other things should stay as |
| 15 |
> they are. |
| 16 |
> |
| 17 |
|
| 18 |
Perhaps this is an argument for a git based portage tree? Master can |
| 19 |
stay as the current status quo and anyone who wants to can maintain a |
| 20 |
branch or fork which points to a slightly different subset of the tree? |
| 21 |
|
| 22 |
I doubt we actually have the capacity to make this work, but it would at |
| 23 |
least in theory be cool to have a (weekly/monthly) branch which gets |
| 24 |
cut, run through a tinderbox in various forms and then pushed? Or if |
| 25 |
someone wants to maintain a redhat style antique set of packages where |
| 26 |
the tree is largely held back to 2005 state with only bug fixes and |
| 27 |
essential packages bumped? |
| 28 |
|
| 29 |
Just thinking... |
| 30 |
|
| 31 |
Ed W |
Archives