-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 28.1.2011 23:42, Rich Freeman napsal(a): > 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:
Wow what a nice and long reply, thanks :) > > 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. > QA is not to discipline any developers. Everyone of us can cause breakage, heck even i killed profiles once :) Only case where we don't want Devrel interfere with QA decision at all is when someone Intentionaly breaks main tree. Seriously if someone really hit this issue i don't actually want him to apologize to another team and pretend like it never happened, i would prefer him long gone in a place far far away :) We really just want keep control over removing access for people that does breakage to main tree just for the breakage itself, aka it can't be excused in any way. """ Lets say you have this change for eclass which affects large part of the tree and on -dev ml people including QA members told you not to do so, yet you still proceed with the commit thus breaking part of the main tree in effect. In this situation normal accidental breakage or uneducated commit can't count in cause you were told of that it is not the way you should do it. So only way it can be described is deliberate act of main tree destruction. Since QA team is responsible for overall quality of main tree it is obvious we as team can't trust such person while he (or she) does not listen to us. So we would like to be the ones who decide that they should not be permitted to do direct commits to main tree. (they for sure can stay developers and write documentation and help in other areas they want to) """ > 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. You actually pretty well described how we work when somebody breaks main tree without its primary intention to nuke it off. Which is still in effect with this update :) (everyone can make typo or forget to ask about something and accidentally do something disasterous :P) """ +* In case a particular developer persistently causes breakage, the QA + lead may request commit rights of given developer to be suspended by + the Infra team. Devrel should then proceed to evaluate the situation, by + finding a compromise or permanently revoking those rights. """ > > 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... Yep QA is responsible for technical aspect of commits where Devrel handles the human side of it, so we usually give what we gather on named bad developer to Devrel to decide what to do with him. > > Rich > Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DS0UACgkQHB6c3gNBRYcVFgCdHxzgXCepKzj0SY3oWCaKQpKR yDYAnj6Wg1Ew7Y8xtypkUXeoQ699/MNf =J775 -----END PGP SIGNATURE-----
