From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
Date: Tue, 21 Jan 2014 10:47:50 -0500 [thread overview]
Message-ID: <CAGfcS_=xfkQe+6BFhdhFfk5A=gD-zunKr7gLO=V36B2TfME6Lg@mail.gmail.com> (raw)
In-Reply-To: <20140121155616.6a8cdf9b@TOMWIJ-GENTOO>
On Tue, Jan 21, 2014 at 9:56 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> If a developer does an unannounced mass action that breaks the tree
> severely or is heavily prohibited by policy, is unreachable while he
> continues to commit this; then it would be handy to "temporarily" be
> able to withdraw the commit access to bring it to that developer's
> attention.
Hadn't really thought about it in this light. In this situation
restricting commit access is being used as a technical solution to a
technical problem - not unlike killing a runaway process.
I have no issues at all with QA taking action in a manner like this,
though unless that mass-update is really slow I doubt we'd ever react
in time.
What I don't like is the idea of QA taking what amounts to punitive
measures. I think that this is a role best held by Comrel. I do
appreciate Markos's comments regarding Comrel not being the right
solution to a technical problem. I do not see Comrel has having a
role in mediating a dispute between QA and a developer over the
correctness of policy or its enforcement (personal conflicts are a
different matter as Markos acknowledges). What I do see Comrel has
having a role in is a developer who simply refuses to follow policy -
whether that is CoC, technical policy, or whatever. In the case of
CoC Cevrel is judge, jury, and executive (that is, they determine
whether it was violated in addition to dealing with the fact that it
was). In the case of a QA issue QA is the jury (they determine if the
policy was violated), and Comrel is the judge and executive (they
determine how to get the dev to go along with policy or get rid of
them).
If Comrel really objects to this I'm not entirely opposed to letting
QA have the reins (certainly we can't just let policy go unenforced
entirely). However, I would encourage the teams to give some thought
as to whether it makes sense to work together to separate the human vs
technical factors here.
This discussion has been helpful...
Rich
next prev parent reply other threads:[~2014-01-21 15:47 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-19 5:02 [gentoo-dev] rfc: formally allow qa to suspend commit rights William Hubbs
2014-01-19 5:07 ` William Hubbs
2014-01-19 5:17 ` [gentoo-dev] " W. Trevor King
2014-01-19 12:46 ` [gentoo-dev] " hasufell
2014-01-20 1:05 ` Tom Wijsman
2014-01-19 20:22 ` Denis Dupeyron
2014-01-20 1:01 ` Tom Wijsman
2014-01-20 1:22 ` Denis Dupeyron
2014-01-20 2:47 ` Tom Wijsman
2014-01-22 16:30 ` Jeroen Roovers
2014-01-20 1:24 ` Alec Warner
2014-01-20 2:54 ` Tom Wijsman
2014-01-20 13:59 ` Rich Freeman
2014-01-20 14:09 ` Alan McKinnon
2014-01-21 0:22 ` Patrick Lauer
2014-01-21 0:46 ` Rich Freeman
2014-01-21 5:29 ` Alec Warner
2014-01-21 5:27 ` Alec Warner
2014-01-22 17:54 ` Ciaran McCreesh
2014-01-22 22:37 ` Andreas K. Huettel
2014-01-22 22:59 ` Tom Wijsman
2014-01-21 14:56 ` Tom Wijsman
2014-01-21 15:47 ` Rich Freeman [this message]
2014-01-21 17:26 ` William Hubbs
2014-01-21 17:50 ` Rich Freeman
2014-01-21 17:56 ` Peter Stuge
2014-01-21 18:11 ` Tom Wijsman
2014-01-21 18:16 ` Peter Stuge
2014-01-21 19:18 ` Tom Wijsman
2014-01-21 21:03 ` Thomas Sachau
2014-01-21 22:56 ` Tom Wijsman
2014-01-21 23:14 ` William Hubbs
2014-01-22 7:00 ` Alan McKinnon
2014-01-22 10:36 ` hasufell
2014-01-22 10:39 ` hasufell
2014-01-22 10:58 ` Alec Warner
2014-01-22 23:29 ` Tom Wijsman
2014-01-22 12:34 ` Patrick Lauer
2014-01-22 19:42 ` Rich Freeman
2014-01-22 23:40 ` Tom Wijsman
2014-01-22 22:06 ` Alan McKinnon
2014-01-22 23:15 ` Tom Wijsman
2014-01-21 23:20 ` hasufell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGfcS_=xfkQe+6BFhdhFfk5A=gD-zunKr7gLO=V36B2TfME6Lg@mail.gmail.com' \
--to=rich0@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox