Subject: Re: Monthly Gentoo Council Reminder for January
Newsgroups: gmane.linux.gentoo.devel
Date: 2008-01-09 17:11:47 GMT (1 year, 25 weeks, 1 day, 3 hours and 56 minutes ago)
I wanted to take this thread in a slightly different direction so that the council has a little more to work with tomorrow. Obviously there are multiple opinions on whether a problem currently exists - and the council will need to decide on this. If no problem currently exists they will likely take no action. However, if a problem does exist, what would be a reasonable solution? Here's a proposal. Maybe not a great one - feel free to come up with others (other than just do nothing - if we are going to do nothing we don't need to work out what that will be). I think it gives arch teams a fair amount of time to keep up with stable requests, but also allows package maintainers to eventually get rid of cruft. The exact timeframes are of course the easiest and most obvious things to modify. My hope is that this will give everybody something to think about so that if a decision to enact policy is made tomorrow the policy is a good one... Ebuild Stabilization Time Arch teams will normally have until the LATER of the following two dates to stabilize ebuilds for non-security-related issues: 1. 60 days from the day the last substantial change was made to the ebuild (clock resets if a non-trivial change is made to the ebuild). That's 30 days to allow the package to be proven stable, and 30 days to do something about it. 2. 30 days from the day a bug was filed and keyworded STABLEREQ and 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). Perhaps the guideline should be one week on both time periods for security bugs. 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 stable keyword request. The bug being resolved counts as a substantial change for the purpose of #1 above. 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 and there IS a technical problem preventing stabilization, but the package is subject to security issues, the maintainer MAY choose to mask the vulnerable versions in package.mask. If an ebuild does not meet the time criteria or there is a technical problem preventing stabilization and there isn't an outstanding security issue, then the maintainer must not remove the highest-versioned stable ebuild for any given arch. Spirit of Cooperation Ebuild maintainers 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. -- gentoo-dev <at> lists.gentoo.org mailing list