| 1 |
On Sun, 19 Jan 2014 10:46:28 +0100 |
| 2 |
Ulrich Mueller <ulm@g.o> wrote: |
| 3 |
|
| 4 |
> Instead, we should come up with a clear set of rules under what |
| 5 |
> circumstances package maintainers are allowed to stabilise ebuilds |
| 6 |
> themselves on all architectures. |
| 7 |
|
| 8 |
The cases where stabilisation is important (for security, progress) are |
| 9 |
usually those where this arbitrary type of stabilisation is not an |
| 10 |
option, unless we drop all pretence of upholding the dictionary meaning |
| 11 |
of "stabilisation". |
| 12 |
|
| 13 |
What we need is architecture teams that clearly do the work (as a team), |
| 14 |
or we drop their stable status. Recent "advances" in stabilisation |
| 15 |
practices certainly haven't helped establish a reliable picture of some |
| 16 |
teams. |
| 17 |
|
| 18 |
If a team cannot keep up stabilising thousands of packages, then it |
| 19 |
should focus in the short term on dropping keywords for "extra" |
| 20 |
packages, and then in the long term focus on getting a reliable base |
| 21 |
system up to date (i.e. drop all the "fun" keywording and focus on what |
| 22 |
that platform really must have to get a system running). |
| 23 |
|
| 24 |
If all that doesn't pan out, then we should set the QA hounds on |
| 25 |
them. :) |
| 26 |
|
| 27 |
|
| 28 |
jer |
Archives