Daniel Goller <[EMAIL PROTECTED]> said: > Mark Loeser wrote: > > Here is the newest revision of my proposal. Not much has changed, but I > > added and changed some small things. Constructive feedback is > > appreciated. I'd like to get this voted on by the council at the next > > meeting. > > > > * The QA team's purpose is to provide cross-team assistance in keeping > > the tree in a good state. This is done primarily by finding and pointing > > out issues to maintainers and, where necessary, taking direct action. > > describe what makes it necessary and what actions will be taken > or if the paragraphs below are meant to do that, you can save that line > in that paragraph
What makes it necessary is if something is broken or goes against
policy, and the actions are listed below. I was pretty sure this went
without saying.
> > * In case of emergency, or if package maintainers refuse to cooperate,
> > the QA team may take action themselves to fix the problem. The QA
> > team does not want to override the maintainer's wishes by default, but
> > only
> > wish to do so when the team finds it is in the best interest of users
> > and fellow developers to have the issue addressed as soon as possible.
>
> define emergency, define as soon as possible (some bugs might be quite
> tricky to track and might be put on back burner and what little time is
> available used on things not taking up equal times), how do you know ia
> dev is not cooperating or if i he/she is just prioritizing
emergency - something that is broken and affects a great number of users
as soon as possible - exactly what it says, as soon as possible
Basically, use common sense here please :)
> > * In the case of disagreement on policy among QA members, the majority
> > of established QA members must agree with the action.
>
> you shouldn't disagree about this policy, or you might as well not have
> this document, write disagree on the solution maybe?
It was not referring to *this* policy, but the exact policy that is
dealing with the problem at hand. In this context, it was meant to be
read that what some of us to believe is a problem is actually a problem
here, and that the solution is reasonable. I will write the whole thing
out to improve clarity.
> > * Just because a particular QA violation has yet to cause an issue does
> > not change the fact that it is still a QA violation.
>
> Then you must be talking about coding style here? remove the point and
> add it above to coding style, as an example why you will deal with the
> coding style maybe? no other violation should be left to such vagueness
No, I'm talking about problems that were not noticed before and we just
realized the implications of what we are doing.
> > * If a particular developer persistently causes breakage, the QA team
> > may request that devrel re-evaluates that developer's commit rights.
> > Evidence of past breakages will be presented with this request to
> > devrel.
>
> define persistently, how do you presistently cause breakage? maybe this
> is one of those non native english speaker moments, but doesn't that
> mean like every commit is botched?
Not every commit, but a recognizable pattern can be seen.
> > * The QA team will maintain a list of current "QA Standards" with
> > explanations as to why they are problems, and how to fix the problem.
> > The list is not meant by any means to be a comprehensive document, but
> > rather a dynamic document that will be updated as new problems are
> > discovered. The QA team will also do their best to ensure all developer
> > tools are in line with the current QA standards.
>
> as said in the other two posts, maybe write it is a comprehensive list,
> just that it is not finite? that might clear this point up.
The wording as it currently stands is what I mean for it to say. Our
document should never be considered to cover *every* single thing you
can do wrong. It also covers that the document is never complete, and
that we are always working on improving it.
> > * QA will take an active role in cleaning up unmaintained and broken
> > packages from the tree. It is also encouraged of members of the QA team
> > to
> > assist in mentoring new developers that wish to take over unmaintained
> > packages/herds.
> >
> >
>
> i am not sure how to read this one, it could mean broken packages that
> are unmaintained, but how it is written it could also mean unmaintained
> || broken, not only unmaintained && broken, i really wish you would at
> least consider not killing off unmaintained and not broken packages, and
> word it in some way that this comes out clear in that paragraph
It is written exactly how I meant for it to be interpretted. We will be
removing things that are unmaintained *and* broken. I'm sure the
security team will agree that this is a problem that currently plagues
them as well, and I think we can help them out by doing what we can in
this regard.
--
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
pgp516QuKnJqE.pgp
Description: PGP signature
