public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alec Warner <antarus@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
Date: Mon, 20 Jan 2014 21:29:34 -0800	[thread overview]
Message-ID: <CAAr7Pr_U=udKASK9cpPBbbsCUjLv=kYPg_Cj3PQ3z2j_s5ENsw@mail.gmail.com> (raw)
In-Reply-To: <CAGfcS_=of0GG2fLrzkvsApmrW9UkVNG7akg_q8MeV9N6eLYHvQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]

On Mon, Jan 20, 2014 at 4:46 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> >
> > Yey, we're allowed to sometimes do revert games, if we're asking nicely
> > ... and the only way to stop the revert game is for QA to stand down.
> > We're allowed to send strongly-worded emails, but getting things baked
> > into policy is too radical.
>
> So, here is how I reconcile this.  There are basically two kinds of
> problems - technical problems, and people problems.  We need to deal
> with both.  I see QA as being primarily responsible for technical
> problems, and it should be staffed to deal with them.  I'm fully
> supportive of it being a policy-creating body, with the Council being
> the place to vet any policies that seem controversial.
>
> If an ebuild has a deficiency, that's a technical problem - QA should
> step in.  QA should also educate the maintainer so that they
> understand how to avoid the problem in the future.
>
> Suppose the maintainer refuses to take the problem seriously (whether
> they're just lazy, incompetent, or malicious).  Now, that is a people
> problem, and really shouldn't be QA's responsibility to deal with
> beyond pointing it out to Comrel.
>
> Comrel should deal with people problems, and they should be staffed
> accordingly.  They need the manpower so that they can deal with them
> efficiently.  When QA says that a developer is not following a
> technical policy, Comrel should defer to them as this is their area of
> expertise.  If either QA or Comrel gets out of hand there is always
> the appeal to Council, so neither body needs to be walking on
> eggshells or taking 18 months to decide to do something about a
> problem.  If QA feels like Comrel isn't taking their complaints
> seriously, there is the Council - Comrel should be taking their
> concerns seriously.  However, QA needs to recognize that people
> problems aren't always best solved with the use of command-line
> utilities.
>
> In then end we'll only get where we need to be if we work together,
> and avoid the passive-aggressive nonsense.  If somebody feels that QA
> is out of line by all means put it on the Council agenda.  Otherwise,
> devs need to do what they can to make the job of QA easier, and not
> harder.
>
> About the only time I really see need for "emergency suspension
> powers" is in the situation of some kind of hacking attempt.  I'm not
> aware of any attack like this ever being mounted, but if it were the
> necessary action would involve a lot more than just suspending
> somebody's commit rights.  Probably the best first action would be to
> disable all rsync/etc distribution, lock down cvs entirely, and then
> begin cleanup.
>
>
I can only think of one incident, and once we learned of the incident that
developer was let go.



> If there is some kind of general standing problem of Comrel ignoring
> QA by all means let the Council know (assuming you can't just work it
> out with them).  However, Comrel announced not all that long ago a
> general desire to enforce CoC with short bans/etc, and that they were
> interested in having a vital QA organization so that they have some
> kind of authority to rely on for technical questions.  That certainly
> sounds like a good direction to me, so I don't want to dwell too much
> on the past.
>
> Bottom line - don't be afraid to do your job, and when something gets
> in the way speak up about it!
>
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 4373 bytes --]

  reply	other threads:[~2014-01-21  5:29 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 [this message]
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
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='CAAr7Pr_U=udKASK9cpPBbbsCUjLv=kYPg_Cj3PQ3z2j_s5ENsw@mail.gmail.com' \
    --to=antarus@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