Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Thomas Sachau <tommy@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]

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.

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]