Instead of addressing archs as being slackers or not, this addresses it as a more granular layer of looking at ebuilds. Thanks to Richard Freeman for the initial proposal that I based this off of. Please give me feedback on this proposal, if you think it sucks (preferably with an explanation why), or if you think it might work. 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. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com