Gentoo Archives: gentoo-dev

From: Grant Goodyear <g2boojum@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] QA Team's role
Date: Mon, 27 Feb 2006 18:09:08
Message-Id: 44033F86.7060805@gentoo.org
In Reply to: [gentoo-dev] [RFC] QA Team's role by Mark Loeser
1 Mark Loeser wrote:
2 > * In case of emergency, or if package maintainers refuse to cooperate,
3 > the QA team may take action themselves to fix the problem.
4
5 My suspicion is that the more common problem is going to be inaccessible
6 developers, rather than uncooperative ones. Certainly, if a maintainer
7 cannot be contacted, then I would prefer that QA fix the problem rather
8 than let it languish. So, yes, I do believe that QA needs the ability
9 to go in and change any package that is broken. (It's worth noting,
10 though, that every dev w/ tree access already has that ability, and the
11 only real issue is the amount of pain that will be inflicted on a dev
12 who changes packages both without permission and without skill. Very
13 few devs will complain about somebody improving packages even without
14 permission as long as the improvement is done well.)
15
16 > * In the event that a developer still insists that a package does not
17 > break QA standards, an appeal can be made at the next council meeting. The
18 > package should be dealt with per QA's request until such a time that a
19 > decision is made by the council.
20
21 I'm somewhat ambivalent on this one on a couple of points, and the
22 nxserver case (bug #123926) hits both of them. The first is that it
23 seems to me that in a case like this one, where the package involved is
24 a minor one that (I think) is not a dependency of any other packages,
25 the most that QA should do is hard mask the package w/ a clear note
26 pointing to the bug report, until some sort of resolution is achieved.
27 Removing the package would seem to be a bit much. The second is the
28 fact that I don't really like seeing policy bounced to the council
29 unless absolutely necessary. Just as was seen here, a discussion on
30 -dev might well lead to a reasonable compromise. If it doesn't, then
31 the council can get involved.
32
33 Of course, that leaves the question of who decides on the severity of a
34 QA violation? Well, I would suggest that the QA team does, at the risk
35 of getting publicly smacked down if they choose poorly.
36
37 -g2boojum-

Attachments

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

Replies

Subject Author
Re: [gentoo-dev] [RFC] QA Team's role Ciaran McCreesh <ciaranm@g.o>
Re: [gentoo-dev] [RFC] QA Team's role Mark Loeser <halcy0n@g.o>