Mark Loeser wrote: > * In case of emergency, or if package maintainers refuse to cooperate, > the QA team may take action themselves to fix the problem.
My suspicion is that the more common problem is going to be inaccessible developers, rather than uncooperative ones. Certainly, if a maintainer cannot be contacted, then I would prefer that QA fix the problem rather than let it languish. So, yes, I do believe that QA needs the ability to go in and change any package that is broken. (It's worth noting, though, that every dev w/ tree access already has that ability, and the only real issue is the amount of pain that will be inflicted on a dev who changes packages both without permission and without skill. Very few devs will complain about somebody improving packages even without permission as long as the improvement is done well.) > * In the event that a developer still insists that a package does not > break QA standards, an appeal can be made at the next council meeting. The > package should be dealt with per QA's request until such a time that a > decision is made by the council. I'm somewhat ambivalent on this one on a couple of points, and the nxserver case (bug #123926) hits both of them. The first is that it seems to me that in a case like this one, where the package involved is a minor one that (I think) is not a dependency of any other packages, the most that QA should do is hard mask the package w/ a clear note pointing to the bug report, until some sort of resolution is achieved. Removing the package would seem to be a bit much. The second is the fact that I don't really like seeing policy bounced to the council unless absolutely necessary. Just as was seen here, a discussion on -dev might well lead to a reasonable compromise. If it doesn't, then the council can get involved. Of course, that leaves the question of who decides on the severity of a QA violation? Well, I would suggest that the QA team does, at the risk of getting publicly smacked down if they choose poorly. -g2boojum-
signature.asc
Description: OpenPGP digital signature
