Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Rich Freeman]

2011/1/28 Tomáš Chvátal <scarabeus@g.o>:
> So draft we would like to have implemented as Glep update is this diff:
> http://dev.gentoo.org/~scarabeus/glep-0048.diff
>
> Please comment and help us improve the "english" of the whole document
> so it gets accepted :)

My only general comments are:

1.  It makes sense that in the event that a "Rogue" developer is
wreaking havoc on the tree that QA can get infra to suspend their
commit rights.  That's safeguarding the tree in the face of imminent
harm.  This should generally be limited to serious issues (people
running scripts to mass-update packages, bad changes to system
packages, etc), and not because there is some dispute over whether
some obscure package should or should-not be masked.

2.  I don't think it makes sense for QA to discipline developers
permanently in these cases.  They should suspend access pending Devrel
resolution of the issue.  Devrel should of course strongly consider
the input of QA.

If Devrel is not adequately doing its job then this should be
escalated to the Devrel lead, or if necessary to the council (who can
step in if truly necessary).  In the face of imminent harm QA can
always get a temporary ban on commits from infra.  If this goes back
and forth (QA banning, Devrel unbanning) then I'm sure the council
will step in.

So, in a nutshell here is how it works:

1.  Developer starts messing something up (some crazy script is
committing junk to the tree, or dev is making some change to critical
package, or whatever).
2.  QA notices, or is told, or whatever.
3.  QA tries to ping dev - with severity of problem dictating how long
they should wait to resolve directly.
4.  QA determines that dev is unwilling to resolve a critical issue,
or cannot be reached and the matter can't wait.
5.  QA contacts infra, and infra suspends commit access to contain the damage.
6a.  QA initiates repairs (whatever this takes - they don't need to
personally do the work, etc).
6b.  QA logs complaint with DevRel.
7.  Devrel follows their process to resolve issue.  Developer remains
banned until Devrel feels they can be unbanned, or dismissed.  Devrel
takes input from QA.

If the issue here is that the Devrel and QA leads differ as to some
matter of policy or whatever, the council should be asked to resolve.
While the QA and Devrel teams may tend to self-govern, I don't think
the intent is that we end up having "three" Gentoos - the one ruled by
Devrel, the one ruled by QA, and the one ruled by the Council (not to
mention the Trustees).

In practice I haven't really seen any situations where we're really
having problems over this, so I don't want to start a war over
something that isn't even a problem.

In any case, the solution for developers is simple:

1.  Don't do stupid stuff to the tree such that you tick EVERYBODY off.
2.  If you want to do something to the tree that you think is right
but which might tick a lot of people off (whether they are QA or not),
post notice of it in -dev first.
3.  If you and QA can't work it out before you do it, then work it out
with the council or something.
4.  Generally act like an adult.  :)

Ok, that was probably overly verbose.  I don't see any issues with the
wording in the diff - this is more a matter of which is the right
policy.

Finally, if Devrel, QA, and the Council have already talked this out
and agree that QA is in the best place to police technical commit
issues, then pipe this email to /dev/null...

Rich