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

Attachment: signature.asc
Description: Digital signature

Reply via email to