FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-28-2011, 08:11 PM
Tomáš Chvátal
 
Default Glep 48 update (as nominated for next meeting)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
first off i would like to apologize for not sending this mail sooner
(helluva week).

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

Cheers

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1DMQIACgkQHB6c3gNBRYdXPgCgu0/rITuXTPLkngR/CMVVjXs3
hx0AnAxONMKBw1fRR27V1RdA5Hx/rk4/
=xSmN
-----END PGP SIGNATURE-----
 
Old 01-28-2011, 09:42 PM
Rich Freeman
 
Default Glep 48 update (as nominated for next meeting)

2011/1/28 Tomáš Chvátal <scarabeus@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
 
Old 01-28-2011, 10:03 PM
Tomáš Chvátal
 
Default Glep 48 update (as nominated for next meeting)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 28.1.2011 23:42, Rich Freeman napsal(a):
> 2011/1/28 Tomáš Chvátal <scarabeus@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/

iEYEARECAAYFAk1DS0UACgkQHB6c3gNBRYcVFgCdHxzgXCepKz j0SY3oWCaKQpKR
yDYAnj6Wg1Ew7Y8xtypkUXeoQ699/MNf
=J775
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 03:16 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org