Grant Goodyear <[EMAIL PROTECTED]> said: > 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.
We hope that it is never the case when someone refuses to cooperate, but
it is a possible situation we may likely have to deal with at some
point.
> > * 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.
I agree. With regards to the nxserver case, we said the package should
be removed if we could not come to a resolution. We never said that we
were going to outright remove the package immediately.
It is not our goal, nor our intent, to go around and remove people's packages
from the tree. This entire bullet point is really a worst case scenario when
all else breaks down. The same with if there is a disagreement within the
majority of the QA team. I don't foresee this occuring often, if at
all, but I felt it was important enough to address.
--
Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86)
email - halcy0n AT gentoo DOT org
mark AT halcy0n DOT com
web - http://dev.gentoo.org/~halcy0n/
http://www.halcy0n.com
pgpBVWM0NwbfO.pgp
Description: PGP signature
