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 discussion: 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). Tobias
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
