Proposal v1

slacker_arches.txt (text/plain), 1.57 KB, created by Mark Loeser (RETIRED) on 2008-11-10 18:23:37 UTC

Ebuild Stabilization Time

Arch teams will normally have 30 days from the day a bug was filed, keyworded
STABLEREQ, the arch was CCed, and the maintainer either filed the bug or
commented that it was OK to stabilize (clock starts when all of these
conditions are met).

Security bugs are to be handled by the policies the Security Team has
established.

Technical Problems with Ebuild Revisions

If an arch team finds a technical problem with an ebuild preventing
stabilization, a bug will be logged as a blocker for the keyword request.  The
bug being resolved resets the time for the 30 days the arch team has to mark
the ebuild stable.

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.

If an ebuild meets the time criteria above, but there is a technical issue
preventing stabilization, and there are no outstanding security issues, then
the maintainer MUST not remove the highest-versioned stable ebuild for any
given arch without the approval of the arch team.

Security issues are to be handled by the recommendations of the Security Team.

Spirit of Cooperation

Ebuild maintainer and arch teams are encouraged to work together for the sake
of each other and end users in facilitating the testing and maintenance of
ebuilds on obscure hardware, or where obscure expertise is needed.  Package
maintainers are encouraged to use discretion when removing ebuilds in
accordance with this policy.