Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

On Mon, 27 Feb 2006 09:00:15 +0000 "Stuart Herbert"
<stuart.herbert@×××××.com> wrote:
| > Again, then we are going to get into the argument of the definition
| > of an emergency and never be able to get anything done.  We really
| > hope problems never come down to this, which is why we left it
| > worded this way.
| 
| Me too.  But it will, sooner or later, and when something isn't an
| emergency, there's no reason why a change cannot wait until the
| dispute has been resolved.

And, when such a case occurs, there's nothing *requiring* QA to commit
before the dispute is resolved. It's extremely likely that QA will work
hard to ensure that everyone is happy before something gets changed.
However, there are situations where waiting for a month would lead to
considerable damage, and in those situations QA must be free to act.

| Without these safeguards, my feeling is that the QA team is free to
| enforce without concensus at all times.  I don't believe that is in
| the best interests of Gentoo, and is a significant shift in the way we
| govern ourselves.

The only change is that someone will actually be doing the enforcing,
rather than allowing egregious QA violations to sit in the tree for
years because one or two developers refuse to accept that what they're
doing is wrong.

| I don't see any compelling reason for the QA team to be judge, jury
| and executioner, with the council acting as a post-execution appeals
| panel.

'Executioner' is far too harsh a term. QA is fixing packages. QA is not
permanently removing developers from the project, nor even suspending
commit access.

| Wasn't devrel broken up into separate investigation and
| enforcement teams over these very same concerns, raised by a member of
| the QA team?

Heh. This is a perfect example of argumentum ad hominem. It's also an
invalid argument, since there's a huge difference between fixing a
package and kicking off a developer.

| You haven't presented that evidence, or if you have, I haven't seen it
| since getting up this morning.

Dude. You had to write it up in your user guide. That's a pretty good
indication that something is extremely screwed up.

| Instead, we have a proposed QA policy that says "we're always right,
| and when we're not, we still get our way until you convince the
| council to let you back out the changes we demand."  I think that's
| unreasonable.  That's why I oppose this point.  To me, it smacks of
| wanting to have your own way whether you're right or not.  I can't
| support that.

No, it says that the QA team can, where necessary, act without having
to wait for a month for a council decision.

| As already mentioned, if it's not documented, how on earth do you
| expect to raise the general quality of the QA done by each and every
| developer?  How do you expect to be able to consistently enforce your
| own QA standards?
| 
| If it's not documented, then you're left with making it up as you go
| along.  That's in no-one's interest.

Are you saying that because it's not documented that one should not
call mkdir in global scope, the QA team cannot expect people to know
not to do so?


| This comes back to my point about the QA team needing to be an
| educational role first and foremost.

Sure. No-one's disputing that. Hence why we're filing all these bugs,
rather than just fixing things straight off.

| It's not silly.  What do you have to fear about having your proposed
| QA standards backed by key teams?  If your arguments have merit, they
| will be supported.

Abuse from people like you whenever someone finally gets brave enough
to document all the ways in which webapp-config is broken.

| I think you're already abusing that power, by calling for a package to
| be removed when it's causing no trouble to anyone, and when the
| workarounds create a worse user experience than what is already there.
|  When the developer in question declines to remove the package, your
| response is a proposed QA mandate that is unbalanced.

No no no. We asked for the package to be fixed. You refused, and
repeatedly closed the bug on us. Since QA couldn't fix the package
cleanly without help from the maintainer, the more drastic solution was
proposed. Had you, instead of closing the bug and refusing to
acknowledge the problem, offered alternatives straight away, QA could
have worked with you to get the thing fixed. This has happened on other
QA bugs, where a developer thought of a different solution to the
problem -- on other bugs, there was no problem because said developer
started a discussion rather than closing the bug off as WONTFIX,
INVALID or CANTFIX.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm