2011/1/28 Tomáš Chvátal <scarab...@gentoo.org>: > 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
