Gentoo Archives: gentoo-dev

From: Matthew Thode <prometheanfire@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Wed, 15 Jan 2014 17:20:05
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by Tom Wijsman
1 On 01/15/2014 10:57 AM, Tom Wijsman wrote:
2 > On Wed, 15 Jan 2014 15:33:28 +0400
3 > Sergey Popov <pinkbyte@g.o> wrote:
4 >
5 >> 15.01.2014 06:42, Tom Wijsman пишет:
6 >>> And for that occasional mis-guess, *boohoo*, the user can just file
7 >>> a bug; which ironically even happens occasionally for stable
8 >>> packages.
9 >>
10 >> If we blindly approves increasing of such mis-guesses, then our QA
11 >> level in arch teams will down below the apropriate level IMO. And
12 >> this is not good first of all for our stable users.
13 >
14 > What I'm saying is that even on arch team stabilized ebuilds bugs
15 > getting filed happens as well; so, it happening for a maintainer
16 > stabilized ebuild wouldn't be so problematic from that perspective.
17 >
18 > But, indeed, it depends on which arch team procedure efforts the
19 > maintainer actually applies; on an own arch it is quite possible for
20 > the maintainer to be near the QA level of the arch team, whereas not
21 > having access to a certain architecture can indeed become problematic.
22 >
23 > So, for the arches the maintainers do have, it depends on what the
24 > maintainers do as much as what the arch teams do; and to be realistic
25 > arch teams might not always do everything as intended, especially under
26 > time pressure. In my opinion, a maintainer would even spend more time.
27 >
28 > As for arches the maintainer does not have, the available machines
29 > might be usable; though the doubt is whether they have enough power.
30 >
31 > Most of this discussion is hypothetical assuming stabilization stays
32 > (or continues to grow to be more) problematic; who knows we might get
33 > to see the opposite effect that this thread yields some new arch team
34 > members, which could make what we've discussed here not necessary in the
35 > short term run. It is clear everyone wants to hold on to the arch teams.
36 >
37 I would like to see the ability for devs to become arch testers for the
38 packages they own on the architectures they have access to. The hard
39 part is enforcing the arch testing guidelines, so maybe this can be
40 considered 'arch tester jr.'.
42 --
43 -- Matthew Thode (prometheanfire)


File name MIME type
signature.asc application/pgp-signature