On Sun, 19 Jan 2014 10:46:28 +0100
Ulrich Mueller <[email protected]> wrote:
> Instead, we should come up with a clear set of rules under what
> circumstances package maintainers are allowed to stabilise ebuilds
> themselves on all architectures.
The cases where stabilisation is important (for security, progress) are
usually those where this arbitrary type of stabilisation is not an
option, unless we drop all pretence of upholding the dictionary meaning
of "stabilisation".
What we need is architecture teams that clearly do the work (as a team),
or we drop their stable status. Recent "advances" in stabilisation
practices certainly haven't helped establish a reliable picture of some
teams.
If a team cannot keep up stabilising thousands of packages, then it
should focus in the short term on dropping keywords for "extra"
packages, and then in the long term focus on getting a reliable base
system up to date (i.e. drop all the "fun" keywording and focus on what
that platform really must have to get a system running).
If all that doesn't pan out, then we should set the QA hounds on
them. :)
jer
