1 |
Grant Goodyear <g2boojum@g.o> said: |
2 |
> Mark Loeser wrote: |
3 |
> > * In case of emergency, or if package maintainers refuse to cooperate, |
4 |
> > the QA team may take action themselves to fix the problem. |
5 |
> |
6 |
> My suspicion is that the more common problem is going to be inaccessible |
7 |
> developers, rather than uncooperative ones. Certainly, if a maintainer |
8 |
> cannot be contacted, then I would prefer that QA fix the problem rather |
9 |
> than let it languish. So, yes, I do believe that QA needs the ability |
10 |
> to go in and change any package that is broken. |
11 |
|
12 |
We hope that it is never the case when someone refuses to cooperate, but |
13 |
it is a possible situation we may likely have to deal with at some |
14 |
point. |
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 |
I agree. With regards to the nxserver case, we said the package should |
34 |
be removed if we could not come to a resolution. We never said that we |
35 |
were going to outright remove the package immediately. |
36 |
|
37 |
It is not our goal, nor our intent, to go around and remove people's packages |
38 |
from the tree. This entire bullet point is really a worst case scenario when |
39 |
all else breaks down. The same with if there is a disagreement within the |
40 |
majority of the QA team. I don't foresee this occuring often, if at |
41 |
all, but I felt it was important enough to address. |
42 |
|
43 |
|
44 |
-- |
45 |
Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) |
46 |
email - halcy0n AT gentoo DOT org |
47 |
mark AT halcy0n DOT com |
48 |
web - http://dev.gentoo.org/~halcy0n/ |
49 |
http://www.halcy0n.com |