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

[Tom Wijsman <TomWij@gentoo.org>]

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

On Wed, 15 Jan 2014 15:33:28 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> 15.01.2014 06:42, Tom Wijsman пишет:
> > And for that occasional mis-guess, *boohoo*, the user can just file
> > a bug; which ironically even happens occasionally for stable
> > packages.
> 
> If we blindly approves increasing of such mis-guesses, then our QA
> level in arch teams will down below the apropriate level IMO. And
> this is not good first of all for our stable users.

What I'm saying is that even on arch team stabilized ebuilds bugs
getting filed happens as well; so, it happening for a maintainer
stabilized ebuild wouldn't be so problematic from that perspective.

But, indeed, it depends on which arch team procedure efforts the
maintainer actually applies; on an own arch it is quite possible for
the maintainer to be near the QA level of the arch team, whereas not
having access to a certain architecture can indeed become problematic.

So, for the arches the maintainers do have, it depends on what the
maintainers do as much as what the arch teams do; and to be realistic
arch teams might not always do everything as intended, especially under
time pressure. In my opinion, a maintainer would even spend more time.

As for arches the maintainer does not have, the available machines
might be usable; though the doubt is whether they have enough power.

Most of this discussion is hypothetical assuming stabilization stays
(or continues to grow to be more) problematic; who knows we might get
to see the opposite effect that this thread yields some new arch team
members, which could make what we've discussed here not necessary in the
short term run. It is clear everyone wants to hold on to the arch teams.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]