| 1 |
Instead of addressing archs as being slackers or not, this addresses it |
| 2 |
as a more granular layer of looking at ebuilds. Thanks to Richard |
| 3 |
Freeman for the initial proposal that I based this off of. Please give me |
| 4 |
feedback on this proposal, if you think it sucks (preferably with an |
| 5 |
explanation why), or if you think it might work. |
| 6 |
|
| 7 |
Ebuild Stabilization Time |
| 8 |
|
| 9 |
Arch teams will normally have 30 days from the day a bug was filed, keyworded |
| 10 |
STABLEREQ, the arch was CCed, and the maintainer either filed the bug or |
| 11 |
commented that it was OK to stabilize (clock starts when all of these |
| 12 |
conditions are met). |
| 13 |
|
| 14 |
Security bugs are to be handled by the policies the Security Team has |
| 15 |
established. |
| 16 |
|
| 17 |
Technical Problems with Ebuild Revisions |
| 18 |
|
| 19 |
If an arch team finds a technical problem with an ebuild preventing |
| 20 |
stabilization, a bug will be logged as a blocker for the keyword request. The |
| 21 |
bug being resolved resets the time for the 30 days the arch team has to mark |
| 22 |
the ebuild stable. |
| 23 |
|
| 24 |
Removing Stable Ebuilds |
| 25 |
|
| 26 |
If an ebuild meets the time criteria above, and there are no technical issues |
| 27 |
preventing stabilization, then the maintainer MAY choose to delete an older |
| 28 |
version even if it is the most recent stable version for a particular arch. |
| 29 |
|
| 30 |
If an ebuild meets the time criteria above, but there is a technical issue |
| 31 |
preventing stabilization, and there are no outstanding security issues, then |
| 32 |
the maintainer MUST not remove the highest-versioned stable ebuild for any |
| 33 |
given arch without the approval of the arch team. |
| 34 |
|
| 35 |
Security issues are to be handled by the recommendations of the Security Team. |
| 36 |
|
| 37 |
Spirit of Cooperation |
| 38 |
|
| 39 |
Ebuild maintainer and arch teams are encouraged to work together for the sake |
| 40 |
of each other and end users in facilitating the testing and maintenance of |
| 41 |
ebuilds on obscure hardware, or where obscure expertise is needed. Package |
| 42 |
maintainers are encouraged to use discretion when removing ebuilds in |
| 43 |
accordance with this policy. |
| 44 |
|
| 45 |
|
| 46 |
-- |
| 47 |
Mark Loeser |
| 48 |
email - halcy0n AT gentoo DOT org |
| 49 |
email - mark AT halcy0n DOT com |
| 50 |
web - http://www.halcy0n.com |
Archives