Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Rich Freeman <rich0@gentoo.org>]

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.

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