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- |