On Wed, Jan 15, 2014 at 07:33:45PM +0100, Thomas Sachau wrote: > William Hubbs schrieb: > > > Thoughts? > > > > William > > > > [1] http://bugs.gentoo.org/487332 > > [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt > > > > I see 2 cases here: > > 1. specific or all arch teams allow maintainers to stabilize packages on > their own, when they follow the arch team stabilization rules (e.g. > having a system running with stable keywords for testing the package). > This should not reduce the quality of the stable tree (or only to the > small amount, that some arch testers do additional checks the maintainer > does not do). Reading through this thread, it seems like amd64 and x86 > arch teams already use this policy. This sounds like a reasonable > agreement, so i am supporting this too. > > 2. for arches with no such agreement or where the maintainer does not > have the needed hardware to test, no action for a certain amount of time > usually means, that the arch team is overloaded with work so the only > short- to mid-term solution is to reduce the amount of work resulting in > smaller amount of stable packages. So i am voting for maintainers > dropping stable keywords after a certain amount of time with no actions > (maybe with some notice beforehand). This might result in a mixed arch > user setup by default, but imho it is still better to have a smaller > stable set of core packages and testing packages on top then having > either everything on testing or broken/untested/unsupported packages, > which are still claimed to be the opposite with the stable keyword. > > short summary: > > -in agreement with arch teams, following stabilization policy and having > the needed hardware, maintainers should be able to add stable keywords > themselves > -if either agreement of arch team or needed hardware is missing, > keywords should be dropped, so that after some time the workload matches > the abilities of the arch team again.
When you say "drop keywords" do you mean: 1) revert the old version back to ~arch or 2) remove the old version. As a maintainer, I would rather do 2, because I do not want to backport fixes to the old version. William
signature.asc
Description: Digital signature