Mark Loeser wrote:
> Removing Stable Ebuilds
> If an ebuild meets the time criteria above, and there are no technical issues
> preventing stabilization, then the maintainer MAY choose to delete an older
> version even if it is the most recent stable version for a particular arch.

What if this would break deps or it's a very common package for example
belonging to the set of system packages?

If we would opt for such a fixed timeframe for architectures teams to
fix bugs I'd like to rate those bugs at least partially like security@
does - that would allow us to have different timeframes for
stabilization depending on how much the package in questions is
(expected to be) installed at our users' systems. 

In my opinion we would need to address two main concerns with this
1) What can we do to help understaffed architecture teams?

What about using a tinderbox (yeah, i know - we have lots of tinderboxes
already around) which automatically (re)builds stable-candidates and
those of the candidates which a) includes a test phase and b) pass that
test phase might be stabled by the maintainer/herd and not only the
architecture team, for example?

2) When do we move an architecture back to ~arch?

We would need to define a threshold of when an stable architecture has
to enter a probation period (and who and what's going to start that
process) and a timeframe after which either the architecture is moved
back to ~arch or the architecture team has proven that it is able to
maintain stable keywords (define who's going to decide this).

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reply via email to