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@lists.gentoo.org mailing list
