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 |