Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Wed, 22 Jan 2014 14:42:14 -0500
Rich Freeman wrote:
> So, this was what I was trying to get at in my email. I see a couple
> of different models being thrown around and they really differ on the
> guidelines as to how QA would apply the power to suspend devs.
Looking at the rest of your mail besides this; I think that what needs
to be discussed further is which cases would be a ComRel matter and
which cases would not be.
There are some loosely defined borders we know of ("technical",
"personal", "CoC violation", "breakage", ...) but when it comes to
matters that lie on the borders of the above or there are combinations
possible, I think we have some situations where both solutions may be
possible, maybe we should try to work these out a bit further.
As when we would wait till it happens and then start to discuss whose
matter this is, it would form a problem as well as a delay.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Wed, 22 Jan 2014 02:58:45 -0800
Alec Warner wrote:
> Of course it is. We want to send the message that if a person's
> contributions are not up to par, their access to commit to the
> project will be revoked, until they can prove that they can
> contribute at a level that is not detrimental to users or other
> developers. A large portion of the QA team's role in Gentoo is to
> define what 'par' means and at some level, get the community to agree
> with them.
>
> Developer mentorship, for example, generally requires that a
> prospective developer submits changes to their mentor and the mentor
> reviews them. Part of that process is to determine that prospective
> developers can contribute at the expected level and we have quizzes
> to try and verify that developers understand key facets of ebuild
> development. Certainly if a prospective developer routinely submits
> faulty ebuilds and doesn't show improvement, we are unlikely to grant
> them commit access.
True; becoming a developer goes further than obtaining access, it also
involves keeping that access. And everyone knows well enough that it
takes more than a single breakage to permanently lose that access; to
determine where the limits are, one can remember the case with
python-exec where you see that the developer is still around.
Permanently losing it thus takes quite a big effort; in comparison, a
temporary suspension is something rather helpful ("Oh, were I breaking
the tree? Thanks for preventing me from making further damage; sorry, I
forgot to check IRC and/or e-mails. What can we do to fix it?"),
temporary suspensions do not have to be worried about.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Wed, 22 Jan 2014 09:00:14 +0200 Alan McKinnon wrote: > I don't want to appear rude, but when reading this entire mail all I > see is someone who has probably never had to do it for real. Can you avoid top posting? Had to scroll down to see who you reply to. > People are not machines. Volunteers really do not like having their > freely given time nullified and access removed because one person > thought it was deserved. We take a positive approach instead, access is "temporarily suspended". > Do you realise the message that is sent by denying someone access? You > are saying that person is not good enough to work on Gentoo. Do you > really want to send that message? That is an assumption and depends on the actual message you send to that person; "temporarily suspending" someone goes with a reason. If that reason is to talk with the person as to fixing up the breakage, where afterwards the access gets restored; we're sending a different message. > Vast wholescale breakage is very rare and not something you can base > policy on. Policy is there to prevent wholescale breakage; imagine Gentoo without a policy present, that would be very rare. What do you then base on? > Rich's most recent reply is the most sane proposal I've seen so far. > Revoking access is a human problem and is solved with human solutions. Which message? Why is it the most sane? > Do beware the law of unintended side-effects. Or unexpected benefits? Yes, a law exists; but what are the benefits compared to the cost? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Wed, 22 Jan 2014 17:54:00 + Ciaran McCreesh wrote: > On Tue, 21 Jan 2014 08:22:23 +0800 > Patrick Lauer wrote: > > And the biggest "flamewar" so far was about cosmetic issues. > > Y'know, if I get around to it I'll try to work towards making most > > of these warnings fatal, then you can't accidentally add such > > things. (And people not using repoman will have some extra fun!) > > Well couldn't QA start focusing on non-cosmetic issues? I can provide > a list if you need it. > Yes, we already do; fixing reverse dependencies that break on a bump, migrating ebuilds away from deprecated EAPIs, working on QA bugs, ... ... but a list with more ideas is very welcome. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
Am Mittwoch, 22. Januar 2014, 18:54:00 schrieb Ciaran McCreesh: > On Tue, 21 Jan 2014 08:22:23 +0800 > > Patrick Lauer wrote: > > And the biggest "flamewar" so far was about cosmetic issues. > > Y'know, if I get around to it I'll try to work towards making most of > > these warnings fatal, then you can't accidentally add such things. > > (And people not using repoman will have some extra fun!) > > Well couldn't QA start focusing on non-cosmetic issues? I can provide a > list if you need it. Actually, from what I gathered on IRC, suggestions would be appreciated! (but better in separate threads! :) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On 01/22/14 14:34, Patrick Lauer wrote: >> Do you realise the message that is sent by denying someone access? You >> > are saying that person is not good enough to work on Gentoo. Do you >> > really want to send that message? > Yes. And I have no problem being the Evil Guy who pulls the trigger, > err, presses the enter key. > > You are saying that *any* contribution should be accepted just to not > hurt someones feelings. No, I'm not even remotely saying that. Please go back and read gain what I did say. I never mentioned anything about "any contribution". What I did say comes after the qualifier "by denying someone access", which is a very far cry indeed from "any contribution". I also have no problem being the Evil Guy, because I am that sonofabitch. I really know what happens when you suspend/nuke/delete access because I have done it. And every single time it was the wrong thing to do. The only time it was acceptable is for a runaway script or similar, or an honest mistake where I can fix the fallout far faster than the user can. As the sysadmin and root, I know more about the systems than the users do, similarly in Gentoo land it's a fair assumption that the average QA person is more knowledgeable about the tree and policies than the average dev. So when QA takes action in a spirit of help and with communication in place, all is good and things usually work out well. When it swings the other way and suspension is done as a means of punishment (to whatever degree) then QA has stepped beyond the bounds of what QA is about and into something else. I still don't see any suggestions in this thread on how to limit the scope of what QA wants. No-one will seriously try prevent a good QA guy from limiting damage, but what happens when QA itself abuses the policy? And it will happen, we both know this. How does QA propose to curb that downside? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Wed, Jan 22, 2014 at 7:34 AM, Patrick Lauer wrote: > On 01/22/2014 03:00 PM, Alan McKinnon wrote: >> I don't want to appear rude, but when reading this entire mail all I see >> is someone who has probably never had to do it for real. >> >> People are not machines. Volunteers really do not like having their >> freely given time nullified and access removed because one person >> thought it was deserved. > > Well ... > > if these persons actively break things, and endanger others, *and* they > don't respond to multiple verbal warnings/threats ... > > ... what would you do? So, this was what I was trying to get at in my email. I see a couple of different models being thrown around and they really differ on the guidelines as to how QA would apply the power to suspend devs. One scenario that came up is the runaway script. Some dev is doing something that is going to create a lot of work to fix and it gets noticed. QA can't quickly ping them, so they suspend access to halt the damage. Presumably they then fire off an email saying, "hey, I noticed your script was doing foo and suspended your access to halt it until we talk about it - let me know when you've terminated your scripts and I'll get your access reinstated - ping me when you get a chance." That's very different from the scenario you're suggesting, which amounts to deliberate ignoring of warnings and thus they require a semi-permanent ban that might become permanent. The first scenario could happen to the best of us. The second shouldn't. The first is purely a technical solution to a technical problem. The second is a people problem, being mitigated with a technical solution. A ban might be inevitable, but what should the process be? Has the QA team discussed this internally and come to some kind of consensus about just what they want their role to actually be? I can see an argument being made for many different possible roles. What I really am most concerned about is understanding just what the role of QA is and how the way we do QA accomplishes as much as possible with the least burnout for all impacted. I'm all for policy changes in support of this, but I'd rather see us hash out how we want to make it work and turn it into policy and not create a policy and then figure out how to make it work. Rich
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Tue, 21 Jan 2014 08:22:23 +0800 Patrick Lauer wrote: > And the biggest "flamewar" so far was about cosmetic issues. > Y'know, if I get around to it I'll try to work towards making most of > these warnings fatal, then you can't accidentally add such things. > (And people not using repoman will have some extra fun!) Well couldn't QA start focusing on non-cosmetic issues? I can provide a list if you need it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sun, 19 Jan 2014 13:22:07 -0700 Denis Dupeyron wrote: > Yes, thoughts, absolutely. Asking for QA to be at the same time judge, > party and executioner. Need I say more? Actually, infra would be the executioner. Also, as already pointed out, this practice was established a very long time ago, long before GLEP 48 was established. Regards, jer
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On 01/22/2014 03:00 PM, Alan McKinnon wrote: > I don't want to appear rude, but when reading this entire mail all I see > is someone who has probably never had to do it for real. > > People are not machines. Volunteers really do not like having their > freely given time nullified and access removed because one person > thought it was deserved. Well ... if these persons actively break things, and endanger others, *and* they don't respond to multiple verbal warnings/threats ... ... what would you do? Every workplace environment and most opensource projects have some mechanism to enforce sanity in such situations, so why not have it explicitly stated so that there's no one surprised when it triggers? > > Do you realise the message that is sent by denying someone access? You > are saying that person is not good enough to work on Gentoo. Do you > really want to send that message? Yes. And I have no problem being the Evil Guy who pulls the trigger, err, presses the enter key. You are saying that *any* contribution should be accepted just to not hurt someones feelings. Bad news: I don't care about feelings. I care about facts, and results. The *chance* that this happens is luckily small enough, but it does make sense to have an established protocol for such cases. Otherwise any action will be considered "overstepping the boundaries" and/or "breaking the rules", and then there's a huge (social) fallout that could have easily been avoided. Like the discussion we're having now, only amplified a lot. > > Vast wholescale breakage is very rare and not something you can base > policy on. Black swan events are more common than optimists pray for
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Tue, Jan 21, 2014 at 11:00 PM, Alan McKinnon wrote: > I don't want to appear rude, but when reading this entire mail all I see > is someone who has probably never had to do it for real. > > People are not machines. Volunteers really do not like having their > freely given time nullified and access removed because one person > thought it was deserved. > Do you realise the message that is sent by denying someone access? You > are saying that person is not good enough to work on Gentoo. Do you > really want to send that message? > Of course it is. We want to send the message that if a person's contributions are not up to par, their access to commit to the project will be revoked, until they can prove that they can contribute at a level that is not detrimental to users or other developers. A large portion of the QA team's role in Gentoo is to define what 'par' means and at some level, get the community to agree with them. Developer mentorship, for example, generally requires that a prospective developer submits changes to their mentor and the mentor reviews them. Part of that process is to determine that prospective developers can contribute at the expected level and we have quizzes to try and verify that developers understand key facets of ebuild development. Certainly if a prospective developer routinely submits faulty ebuilds and doesn't show improvement, we are unlikely to grant them commit access. > > Vast wholescale breakage is very rare and not something you can base > policy on. > Rich's most recent reply is the most sane proposal I've seen so far. > Revoking access is a human problem and is solved with human solutions. > > Do beware the law of unintended side-effects. > > > > > On 01/21/14 16:56, Tom Wijsman wrote: > > On Mon, 20 Jan 2014 16:09:46 +0200 > > Alan McKinnon wrote: > > > >> Speaking as someone who had this power in his day job, for QA to be > >> able to suspend accounts is a very bad idea indeed. It always ends > >> badly. I suspended 20+ accounts in my current job over the years and > >> the number of cases where it was the right thing to do is precisely 0. > > > > The relation between "using power" and "having power is a bad idea" is > > non-existing; it is rather how that power is used that determines > > whether it is a good idea than whether one is able to use that power. > > > >> It was always a case of ill-advised action taken out of frustration, > >> or bypass the training step, or don't try hard enough to reach the > >> "infringer" and communicate like grown adults. Yup, I did all three. > > > > The prior experience demonstrated here shows how frustration or lack of > > proper communication are really good symptoms to investigate and learn > > from; however, these symptoms seem non-existing with our QA lead. > > > >> Suspending an account is a very serious thing to undertake, the > >> effects on the suspended person are vast and this power should never > >> lie with the person who is feeling the pain. > > > > This is the core symptom of the way you do QA, if you are the person > > that is feeling pain then you need to reconsider your QA position; the > > thing feeling the pain here is the Portage tree, and the QA team is > > just ensuring its quality and thus should not get emotional or > > personally affected by the developers' changes to some bits 'n bytes. > > > > Of course one could see QA as defending the Portage tree with our heart; > > but not that literally, at least not up to the point that one gets > > painfully hurt or even just frustrated... > > > >> Instead, there are well established channels to the body who can make > >> the decision. If QA has a problem with a dev for any reason > >> whatsoever, then QA should make a well-thought out case to that other > >> body for decision. > > > > Adding extra bodies adds more delay; furthermore, these bodies have > > less time, understanding and more about the technical QA issue at hand. > > > > If a developer does an unannounced mass action that breaks the tree > > severely or is heavily prohibited by policy, is unreachable while he > > continues to commit this; then it would be handy to "temporarily" be > > able to withdraw the commit access to bring it to that developer's > > attention. This is under the assumption that we have tried to contact > > the person multiple time and after a reasonable amount of time the > > person has not responded; if we still then need to wait for another > > team to notice, investigate and finally take action whereas we have > > already took the decision, ... > > > > This is rather to note that we need have a talk to coordinate that mass > > action and unbreak the tree, than it is to punish that developer by > > hitting with a ruler on his/her hand; in a sense of "let's fix the > > damage to the tree and proceed". > > > > There even can happen worse things; like misusing 'pkgmove', the > > @system set or similar that can cause some real havoc. It is in this > > occasion where a de
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On 01/22/2014 11:36 AM, hasufell wrote: > > > People already do that without revoking commit access, e.g. when the > recruitment project tells you they don't want to process your recruit > or when project leads don't respond to membership applications at all > or when the ComRel lead is not interested in a private discussion. > > And then they seem surprised when you get pissed. And they even seem > clueless about why the working atmosphere in the gentoo-dev community > is pretty bad. It is not, because someone has a strong opinion. > Everyone has, at times. It's about that attitude of telling people > that you are not good enough for their time. > > So this is already happening. The proposal here is just a "logical" > consequence to this situation. > sorry for messing up that mail, it was a reply to On 01/22/2014 08:00 AM, Alan McKinnon wrote:> I don't want to appear rude, but when reading this entire mail all I see > > Do you realise the message that is sent by denying someone access? You > are saying that person is not good enough to work on Gentoo. Do you > really want to send that message?
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/22/2014 08:00 AM, Alan McKinnon wrote: People already do that without revoking commit access, e.g. when the recruitment project tells you they don't want to process your recruit or when project leads don't respond to membership applications at all or when the ComRel lead is not interested in a private discussion. And then they seem surprised when you get pissed. And they even seem clueless about why the working atmosphere in the gentoo-dev community is pretty bad. It is not, because someone has a strong opinion. Everyone has, at times. It's about that attitude of telling people that you are not good enough for their time. So this is already happening. The proposal here is just a "logical" consequence to this situation. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS358gAAoJEFpvPKfnPDWzIzkH/j/jmHuAIVIy/d+pOya4x4iF 5o/jmqZQ2uYakfRbaISegMb4JtWtlEfjHIyPj2jaIyfBSqfYavfvwZg7pL8st4Kj dB9vGD6P7h0YtK1g8m66XezWwJUD/ym+zgAx3q3M36JfRzKH1rohBlkSQJDivsK3 ogc4bHi9zBXRb1Lpk1OTHdJGTdvUBgqcTEZvTKkAmYZQiNqboCtE3D0euy3u/Osp NYoeDgSdTrAEj3HkAnhujuLZTa/vimDKvde9mRElQVxadrtxxicQ+09Ct8obvC07 zGyQ2BBgINAVMxdNuND7tq0ryT+HnNObkowv2V1My3zhg4tT5CE/7xSOB8CZdak= =H/Gc -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
I don't want to appear rude, but when reading this entire mail all I see is someone who has probably never had to do it for real. People are not machines. Volunteers really do not like having their freely given time nullified and access removed because one person thought it was deserved. Do you realise the message that is sent by denying someone access? You are saying that person is not good enough to work on Gentoo. Do you really want to send that message? Vast wholescale breakage is very rare and not something you can base policy on. Rich's most recent reply is the most sane proposal I've seen so far. Revoking access is a human problem and is solved with human solutions. Do beware the law of unintended side-effects. On 01/21/14 16:56, Tom Wijsman wrote: > On Mon, 20 Jan 2014 16:09:46 +0200 > Alan McKinnon wrote: > >> Speaking as someone who had this power in his day job, for QA to be >> able to suspend accounts is a very bad idea indeed. It always ends >> badly. I suspended 20+ accounts in my current job over the years and >> the number of cases where it was the right thing to do is precisely 0. > > The relation between "using power" and "having power is a bad idea" is > non-existing; it is rather how that power is used that determines > whether it is a good idea than whether one is able to use that power. > >> It was always a case of ill-advised action taken out of frustration, >> or bypass the training step, or don't try hard enough to reach the >> "infringer" and communicate like grown adults. Yup, I did all three. > > The prior experience demonstrated here shows how frustration or lack of > proper communication are really good symptoms to investigate and learn > from; however, these symptoms seem non-existing with our QA lead. > >> Suspending an account is a very serious thing to undertake, the >> effects on the suspended person are vast and this power should never >> lie with the person who is feeling the pain. > > This is the core symptom of the way you do QA, if you are the person > that is feeling pain then you need to reconsider your QA position; the > thing feeling the pain here is the Portage tree, and the QA team is > just ensuring its quality and thus should not get emotional or > personally affected by the developers' changes to some bits 'n bytes. > > Of course one could see QA as defending the Portage tree with our heart; > but not that literally, at least not up to the point that one gets > painfully hurt or even just frustrated... > >> Instead, there are well established channels to the body who can make >> the decision. If QA has a problem with a dev for any reason >> whatsoever, then QA should make a well-thought out case to that other >> body for decision. > > Adding extra bodies adds more delay; furthermore, these bodies have > less time, understanding and more about the technical QA issue at hand. > > If a developer does an unannounced mass action that breaks the tree > severely or is heavily prohibited by policy, is unreachable while he > continues to commit this; then it would be handy to "temporarily" be > able to withdraw the commit access to bring it to that developer's > attention. This is under the assumption that we have tried to contact > the person multiple time and after a reasonable amount of time the > person has not responded; if we still then need to wait for another > team to notice, investigate and finally take action whereas we have > already took the decision, ... > > This is rather to note that we need have a talk to coordinate that mass > action and unbreak the tree, than it is to punish that developer by > hitting with a ruler on his/her hand; in a sense of "let's fix the > damage to the tree and proceed". > > There even can happen worse things; like misusing 'pkgmove', the > @system set or similar that can cause some real havoc. It is in this > occasion where a developer hasn't discussed or talked to anyone earlier > before proceeding with a change he knows he shouldn't do, as well as > ignoring us afterwards; that we simply temporarily cannot allow further > commits, simply because the developer seems "technically unable to > follow the policy and its enforcement". > > This is similar to how you have Gentoo support ops in #gentoo, Gentoo > chat ops in #gentoo-chat and individual ops in individual IRC channels; > if they had to rely on another body which would be the group contacts or > FreeNode, you would have to wait a long for them to kick, ban or mute. > > If the non-technical ComRel lead has this power, then why doesn't the > technical QA lead have this power? After all, the technical lead assures > the quality of what the developer has access to; like I stated above, > the technical lead has more time, understanding and knows the issue. > > You can see this as ComRel improving the QA of the community relations, > whereas QA is improving the QA of the Portage tree and its commits; to > some extent it even becomes questionable why
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2014 03:09 PM, Alan McKinnon wrote: > On 01/20/14 15:59, Rich Freeman wrote: >> On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman >> wrote: >>> #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to >>> suspend people >>> >>> Whether this has actually happened is something that is >>> questionable; >> >> Not that this necessarily needs to make it into the GLEP, and >> I'm still on the fence regarding whether we really need to make >> this change at all, but things like access suspensions and other >> administrative/disciplinary procedures should be documented. I >> think whether this is a matter of public record or not is open to >> debate, but I don't like the fact that we can really say for sure >> when/if this has actually happened. > > > Speaking as someone who had this power in his day job, for QA to be > able to suspend accounts is a very bad idea indeed. It always ends > badly. I suspended 20+ accounts in my current job over the years > and the number of cases where it was the right thing to do is > precisely 0. > > It was always a case of ill-advised action taken out of > frustration, or bypass the training step, or don't try hard enough > to reach the "infringer" and communicate like grown adults. Yup, I > did all three. > > Suspending an account is a very serious thing to undertake, the > effects on the suspended person are vast and this power should > never lie with the person who is feeling the pain. Instead, there > are well established channels to the body who can make the > decision. If QA has a problem with a dev for any reason whatsoever, > then QA should make a well-thought out case to that other body for > decision. Anything else is madness and open invitation for it to > all go south. > > Yep. This proposal is actually another workaround that emerges, because people do not communicate and ignore each other. This is a common habit in the gentoo dev community and it seems we have accepted that fact. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS3wDWAAoJEFpvPKfnPDWzPYYH/A87fN34q1ShBhPvIh2uqP1K UogA7se08pol0abNpDenYM2qDcTxYWXRPgYS7xXcrjh1bbhDmI+/0zuW7vd8/AWh V20TffIkMHr1hMWyFKysFD6VKZC8DYr8fCGkgEfTRAjv1mdGFvfX+k1cqUZ+VtKB bNPiH5Op7EOqpBp/5oz/CmGNFB8nPPEsDRrUbkE/hBPO3JfufBVHdDnmgJg9s0Og Yd5dS55wQTTX7mbLDL4LePDF5pEtM9LnGc2uLgvDrepyX0Z2rio8aNnn/UI0IrY2 p7gkpMK9aA8vSixuvz3qpQbDs0julAswv5ZjTNgu237nukp1yiJGcAwjCDrCRl0= =HdSb -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Tue, Jan 21, 2014 at 11:56:14PM +0100, Tom Wijsman wrote: > On Tue, 21 Jan 2014 22:03:22 +0100 > Thomas Sachau wrote: > > > With this in mind, i currently dont see any case where QA would need > > the ability to remove the commit access of a dev, so i dont see a > > need for this glep update. All, can we please stop this thread on -dev and move it to -project? I specifically asked that after I posted here, but then others, and I guess myself too, did not pay attention to that. Please move to -project to continue the discussion; this really belongs there. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Tue, 21 Jan 2014 22:03:22 +0100 Thomas Sachau wrote: > With this in mind, i currently dont see any case where QA would need > the ability to remove the commit access of a dev, so i dont see a > need for this glep update. The case you have enumerated is just one possible case, this is a case where policy is in place; it is however not always the case that there is policy, or perhaps even that policy is unclear. In these other cases the QA team has to take an actual decision instead of "it is policy"; in such cases, the reasoning behind this becomes technical and you get the whole idea we have been discussing here. Besides that, you also have the possibility for bigger breakages to happen; regardless of whether or not they are written down in policy. In some of these cases the roles of QA and ComRel become questionable; cfr. the whole discussion on #gentoo-qa, where I also asked the reverse question as to why QA has the power to suspend people in a technical area like the Portage tree when it is not part of their terrains. And just to make it clear one more time; it is the ability to "temporarily" "suspend" the commit access, as a means to get the developer to contact us where the developer was otherwise unavailable or intended to not communicate or listen to us. It is no way an actual removal or permanent decision; or well, it might be if this is about repeated behavior, but that's a whole different story... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
Tom Wijsman schrieb: > > [1]: https://wiki.gentoo.org/wiki/GLEP:48 > > "In the event that a developer still insists that a package does > not break QA standards, an appeal can be made at the next council > meeting. The package should be dealt with per QA's request until > such a time that a decision is made by the council." > Thanks for this pointer, i guess this makes the existing situation pretty clear: If QA does a commit and a dev does disagree, he can discuss it with QA or ask for council decision, but should never revert this QA change on his own. So if the dev then does ignore this rule, he does not follow our written rules (problem with the behaviour) and as a result this becomes a case for comrel. Now if comrel cannot convince the dev to accept the QA change (at least until council decision), it means comrel would have to take disciplinary action (e.g. commit access removal). With this in mind, i currently dont see any case where QA would need the ability to remove the commit access of a dev, so i dont see a need for this glep update. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Tue, 21 Jan 2014 19:16:54 +0100 Peter Stuge wrote: > Tom Wijsman wrote: > > > Anyone who cares about quality will be frustrated by others who > > > do not. > > > > We have policies to enforce quality, thus frustration is > > optional. :) > > Policies don't enforce quality, people enforce quality. Well, we have policy [1] stating that QA can enforce quality until overridden by a decision by the Council; so, to be fair, there are even more parties involved than just the policy. Which doesn't change the point; we can enforce quality, thus frustration is optional. :) > And doing that is quickly frustrating. There seems to be a lack of frustration in my experience as a QA member; I care about quality by helping people fix breakage, this gives me a feeling of accomplishment instead of a feeling of frustration. > If enforcing quality would be a purely mechanical task there wouldn't > be the same need for people, which would be ideal. But I think we're > some ways away from that still. We have (Auto)RepoMan and it improves as we speak; we are rather quite close to it, making RepoMan warnings fatal is just a step away. Given there is a lack of frustration, why should we do that? It could cause more frustration than what it is trying to fix. Interesting thought... Could we return back to the original subject of this thread? [1]: https://wiki.gentoo.org/wiki/GLEP:48 "In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council." -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
Tom Wijsman wrote: > > Anyone who cares about quality will be frustrated by others who do not. > > We have policies to enforce quality, thus frustration is optional. :) Policies don't enforce quality, people enforce quality. And doing that is quickly frustrating. If enforcing quality would be a purely mechanical task there wouldn't be the same need for people, which would be ideal. But I think we're some ways away from that still. //Peter pgpl3QhQL_5vy.pgp Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Tue, 21 Jan 2014 18:56:57 +0100 Peter Stuge wrote: > Anyone who cares about quality will be frustrated by others who do > not. We have policies to enforce quality, thus frustration is optional. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
Tom Wijsman wrote: > Of course one could see QA as defending the Portage tree with our heart; > but not that literally, at least not up to the point that one gets > painfully hurt or even just frustrated... Anyone who cares about quality will be frustrated by others who do not. //Peter pgp8g2zJBw06f.pgp Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Tue, Jan 21, 2014 at 12:26 PM, William Hubbs wrote: > On Tue, Jan 21, 2014 at 10:47:50AM -0500, Rich Freeman wrote: >> If Comrel really objects to this I'm not entirely opposed to letting >> QA have the reins (certainly we can't just let policy go unenforced >> entirely). However, I would encourage the teams to give some thought >> as to whether it makes sense to work together to separate the human vs >> technical factors here. > > What about the scenario where qa makes a change, then the dev, in a > civil manor, explains to qa why he prefers his original method and > reverts QA's change without the agreement of QA and without presenting > his case to the council? Now you have another qa violation since GLEP > 48 states that QA's changes must stand until the council says otherwise. > However, assuming the exchanges between qa and the dev are still > respectful, I'm not sure there is a personal issue. It isn't a personal issue, but it is a personnel / human-factors issue. A developer is refusing to follow policy. The CofC is but one policy - all the GLEPs are policy, as is the Devmanual. A developer who refuses to follow policy is subject to action by Comrel. At least, that is how I see the roles of the groups (but I'm open to counter-argument). The other way to do things is to make both groups responsible for what amounts to HR, but then we need to make sure we staff QA accordingly. QA can't then just solve the technical problems and deal with people like you might deal with code, otherwise the Council and/or Comrel really will end up having to deal with a bunch of personal problems. QA stepping in with temporary bans as a band-aid solution to a more serious problem is fine. However, dealing with the inter-personal issues requires a different sort of skillset. A developer who doesn't follow policy is either unable to do so or unwilling to do so. Either problem might be correctable, or perhaps we'll just have to go our separate ways. I think Comrel should be the body that is staffed with the right skills to make that determination. Rich
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Tue, Jan 21, 2014 at 10:47:50AM -0500, Rich Freeman wrote: > If Comrel really objects to this I'm not entirely opposed to letting > QA have the reins (certainly we can't just let policy go unenforced > entirely). However, I would encourage the teams to give some thought > as to whether it makes sense to work together to separate the human vs > technical factors here. Well, I guess that's the big question isn't it -- what is personal vs technical? I think we can all agree that if qa changes an ebuild and a dev comes back with "You stupid *** leave my *** ebuild alone." and reverts qa's change, that is personal and goes straight to Comrel because it is now a CoC violation as well. What about the scenario where qa makes a change, then the dev, in a civil manor, explains to qa why he prefers his original method and reverts QA's change without the agreement of QA and without presenting his case to the council? Now you have another qa violation since GLEP 48 states that QA's changes must stand until the council says otherwise. However, assuming the exchanges between qa and the dev are still respectful, I'm not sure there is a personal issue. wrt the commit rights issue: QA is asking for the ability to *suspend* not *revoke* commit rights. This was explained well by Tom; it is a temporary measure to get a dev's attention if nothing else works. I agree that it is strong. However, if qa gets out of hand with it, the council can always step in and take care of the matter. Thoughts? William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Tue, Jan 21, 2014 at 9:56 AM, Tom Wijsman wrote: > If a developer does an unannounced mass action that breaks the tree > severely or is heavily prohibited by policy, is unreachable while he > continues to commit this; then it would be handy to "temporarily" be > able to withdraw the commit access to bring it to that developer's > attention. Hadn't really thought about it in this light. In this situation restricting commit access is being used as a technical solution to a technical problem - not unlike killing a runaway process. I have no issues at all with QA taking action in a manner like this, though unless that mass-update is really slow I doubt we'd ever react in time. What I don't like is the idea of QA taking what amounts to punitive measures. I think that this is a role best held by Comrel. I do appreciate Markos's comments regarding Comrel not being the right solution to a technical problem. I do not see Comrel has having a role in mediating a dispute between QA and a developer over the correctness of policy or its enforcement (personal conflicts are a different matter as Markos acknowledges). What I do see Comrel has having a role in is a developer who simply refuses to follow policy - whether that is CoC, technical policy, or whatever. In the case of CoC Cevrel is judge, jury, and executive (that is, they determine whether it was violated in addition to dealing with the fact that it was). In the case of a QA issue QA is the jury (they determine if the policy was violated), and Comrel is the judge and executive (they determine how to get the dev to go along with policy or get rid of them). If Comrel really objects to this I'm not entirely opposed to letting QA have the reins (certainly we can't just let policy go unenforced entirely). However, I would encourage the teams to give some thought as to whether it makes sense to work together to separate the human vs technical factors here. This discussion has been helpful... Rich
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Mon, 20 Jan 2014 16:09:46 +0200 Alan McKinnon wrote: > Speaking as someone who had this power in his day job, for QA to be > able to suspend accounts is a very bad idea indeed. It always ends > badly. I suspended 20+ accounts in my current job over the years and > the number of cases where it was the right thing to do is precisely 0. The relation between "using power" and "having power is a bad idea" is non-existing; it is rather how that power is used that determines whether it is a good idea than whether one is able to use that power. > It was always a case of ill-advised action taken out of frustration, > or bypass the training step, or don't try hard enough to reach the > "infringer" and communicate like grown adults. Yup, I did all three. The prior experience demonstrated here shows how frustration or lack of proper communication are really good symptoms to investigate and learn from; however, these symptoms seem non-existing with our QA lead. > Suspending an account is a very serious thing to undertake, the > effects on the suspended person are vast and this power should never > lie with the person who is feeling the pain. This is the core symptom of the way you do QA, if you are the person that is feeling pain then you need to reconsider your QA position; the thing feeling the pain here is the Portage tree, and the QA team is just ensuring its quality and thus should not get emotional or personally affected by the developers' changes to some bits 'n bytes. Of course one could see QA as defending the Portage tree with our heart; but not that literally, at least not up to the point that one gets painfully hurt or even just frustrated... > Instead, there are well established channels to the body who can make > the decision. If QA has a problem with a dev for any reason > whatsoever, then QA should make a well-thought out case to that other > body for decision. Adding extra bodies adds more delay; furthermore, these bodies have less time, understanding and more about the technical QA issue at hand. If a developer does an unannounced mass action that breaks the tree severely or is heavily prohibited by policy, is unreachable while he continues to commit this; then it would be handy to "temporarily" be able to withdraw the commit access to bring it to that developer's attention. This is under the assumption that we have tried to contact the person multiple time and after a reasonable amount of time the person has not responded; if we still then need to wait for another team to notice, investigate and finally take action whereas we have already took the decision, ... This is rather to note that we need have a talk to coordinate that mass action and unbreak the tree, than it is to punish that developer by hitting with a ruler on his/her hand; in a sense of "let's fix the damage to the tree and proceed". There even can happen worse things; like misusing 'pkgmove', the @system set or similar that can cause some real havoc. It is in this occasion where a developer hasn't discussed or talked to anyone earlier before proceeding with a change he knows he shouldn't do, as well as ignoring us afterwards; that we simply temporarily cannot allow further commits, simply because the developer seems "technically unable to follow the policy and its enforcement". This is similar to how you have Gentoo support ops in #gentoo, Gentoo chat ops in #gentoo-chat and individual ops in individual IRC channels; if they had to rely on another body which would be the group contacts or FreeNode, you would have to wait a long for them to kick, ban or mute. If the non-technical ComRel lead has this power, then why doesn't the technical QA lead have this power? After all, the technical lead assures the quality of what the developer has access to; like I stated above, the technical lead has more time, understanding and knows the issue. You can see this as ComRel improving the QA of the community relations, whereas QA is improving the QA of the Portage tree and its commits; to some extent it even becomes questionable why ComRel can suspend access to the Portage tree, but I guess for revert wars between developers. > Anything else is madness and open invitation for it to all go south. This is a too broad generalization on the basis of one use case. See power as an useful temporary tool for when it is absolute necessary, don't see it as a permanent tool for whenever something goes wrong; the former usefulness leads to success, the latter madness leads to sadness. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Mon, Jan 20, 2014 at 4:46 PM, Rich Freeman wrote: > On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer 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. > > I can only think of one incident, and once we learned of the incident that developer was let go. > 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 > >
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Mon, Jan 20, 2014 at 4:22 PM, Patrick Lauer wrote: > On 01/20/2014 10:09 PM, Alan McKinnon wrote: > > On 01/20/14 15:59, Rich Freeman wrote: > >> On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman wrote: > >>> #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to > suspend > >>> people > >>> > >>> Whether this has actually happened is something that is questionable; > >> > >> Not that this necessarily needs to make it into the GLEP, and I'm > >> still on the fence regarding whether we really need to make this > >> change at all, but things like access suspensions and other > >> administrative/disciplinary procedures should be documented. I think > >> whether this is a matter of public record or not is open to debate, > >> but I don't like the fact that we can really say for sure when/if this > >> has actually happened. > > > > > > Speaking as someone who had this power in his day job, for QA to be able > > to suspend accounts is a very bad idea indeed. It always ends badly. I > > suspended 20+ accounts in my current job over the years and the number > > of cases where it was the right thing to do is precisely 0. > > I've been in positions where such powers were not granted, it's worse. > > All you can do is send strongly-worded letters and undo, then wait for > the same thing to be tried again, while telling damagement that this > situation is not good. > > > > > It was always a case of ill-advised action taken out of frustration, or > > bypass the training step, or don't try hard enough to reach the > > "infringer" and communicate like grown adults. Yup, I did all three. > > Some people need more direct clues, and since violence in the workplace > is usually disallowed ... > > > Suspending an account is a very serious thing to undertake, the effects > > on the suspended person are vast and this power should never lie with > > the person who is feeling the pain. Instead, there are well established > > channels to the body who can make the decision. If QA has a problem with > > a dev for any reason whatsoever, then QA should make a well-thought out > > case to that other body for decision. Anything else is madness and open > > invitation for it to all go south. > > > It's a serious thing, so it should have some consequences. > > I'm mildly amused how everyone wants strong QA, but as soon as QA tries > to actually *do* something it's bad, and overstepping their boundaries, > and NIMBY. > > 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. > I think you are framing the argument incorrectly. I'm not suggesting that QA team not have any powers, but that the powers you are asking for are perhaps, not so great. If someone is making tree changes, and they are breaking the tree, and you fix it (using your QA powers to fix it.) Then they revert it. I don't think the proper solution is for QA and a dev to get into a revert war until QA exercises their power to revoke the devs commit access. Simply file a bug and have the developer reprimanded for violating policy. > > And the biggest "flamewar" so far was about cosmetic issues. > Y'know, if I get around to it I'll try to work towards making most of > these warnings fatal, then you can't accidentally add such things. > (And people not using repoman will have some extra fun!) > > Have fun, > > Patrick > > > >
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer 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
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On 01/20/2014 10:09 PM, Alan McKinnon wrote: > On 01/20/14 15:59, Rich Freeman wrote: >> On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman wrote: >>> #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend >>> people >>> >>> Whether this has actually happened is something that is questionable; >> >> Not that this necessarily needs to make it into the GLEP, and I'm >> still on the fence regarding whether we really need to make this >> change at all, but things like access suspensions and other >> administrative/disciplinary procedures should be documented. I think >> whether this is a matter of public record or not is open to debate, >> but I don't like the fact that we can really say for sure when/if this >> has actually happened. > > > Speaking as someone who had this power in his day job, for QA to be able > to suspend accounts is a very bad idea indeed. It always ends badly. I > suspended 20+ accounts in my current job over the years and the number > of cases where it was the right thing to do is precisely 0. I've been in positions where such powers were not granted, it's worse. All you can do is send strongly-worded letters and undo, then wait for the same thing to be tried again, while telling damagement that this situation is not good. > > It was always a case of ill-advised action taken out of frustration, or > bypass the training step, or don't try hard enough to reach the > "infringer" and communicate like grown adults. Yup, I did all three. Some people need more direct clues, and since violence in the workplace is usually disallowed ... > Suspending an account is a very serious thing to undertake, the effects > on the suspended person are vast and this power should never lie with > the person who is feeling the pain. Instead, there are well established > channels to the body who can make the decision. If QA has a problem with > a dev for any reason whatsoever, then QA should make a well-thought out > case to that other body for decision. Anything else is madness and open > invitation for it to all go south. > It's a serious thing, so it should have some consequences. I'm mildly amused how everyone wants strong QA, but as soon as QA tries to actually *do* something it's bad, and overstepping their boundaries, and NIMBY. 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. And the biggest "flamewar" so far was about cosmetic issues. Y'know, if I get around to it I'll try to work towards making most of these warnings fatal, then you can't accidentally add such things. (And people not using repoman will have some extra fun!) Have fun, Patrick
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On 01/20/14 15:59, Rich Freeman wrote: > On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman wrote: >> #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend >> people >> >> Whether this has actually happened is something that is questionable; > > Not that this necessarily needs to make it into the GLEP, and I'm > still on the fence regarding whether we really need to make this > change at all, but things like access suspensions and other > administrative/disciplinary procedures should be documented. I think > whether this is a matter of public record or not is open to debate, > but I don't like the fact that we can really say for sure when/if this > has actually happened. Speaking as someone who had this power in his day job, for QA to be able to suspend accounts is a very bad idea indeed. It always ends badly. I suspended 20+ accounts in my current job over the years and the number of cases where it was the right thing to do is precisely 0. It was always a case of ill-advised action taken out of frustration, or bypass the training step, or don't try hard enough to reach the "infringer" and communicate like grown adults. Yup, I did all three. Suspending an account is a very serious thing to undertake, the effects on the suspended person are vast and this power should never lie with the person who is feeling the pain. Instead, there are well established channels to the body who can make the decision. If QA has a problem with a dev for any reason whatsoever, then QA should make a well-thought out case to that other body for decision. Anything else is madness and open invitation for it to all go south. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman wrote: > #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend > people > > Whether this has actually happened is something that is questionable; Not that this necessarily needs to make it into the GLEP, and I'm still on the fence regarding whether we really need to make this change at all, but things like access suspensions and other administrative/disciplinary procedures should be documented. I think whether this is a matter of public record or not is open to debate, but I don't like the fact that we can really say for sure when/if this has actually happened. Rich
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sun, 19 Jan 2014 17:24:30 -0800 Alec Warner wrote: > We almost never suspend commit rights. I'm not really finding a > situation where this is necessary. Certainly not in the streamlined > fashion proposed here. Well, the QA team has been inactive for a while; so, I guess this might have been a while back. We for example have: #gentoo-qa | * WilliamH has seen flameeys ask infra to lock people out for a time before But also: #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend people Whether this has actually happened is something that is questionable; but yes, one would have to agree that this was definitely streamlined. The idea was on people's minds, probably because that patch was accepted in one of the Council meetings; but streamlining of it never happened. Hence the topic is brought up again here to make a decision final. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sun, 19 Jan 2014 18:22:39 -0700 Denis Dupeyron wrote: > On Sun, Jan 19, 2014 at 6:01 PM, Tom Wijsman > wrote: > > It is more of a "Do we want QA to delegate this through ComRel or > > not?". > > Actually, no. What it is is a "Subject was thoroughly discussed in the > past, and a decision was made." More than once, in fact. What basis do > you have that would warrant more bilkeshedding on this subject? The basis that it has once been accepted as well as another time invited more discussion, clearly indicates that it needs further bikeshedding: http://www.gentoo.org/proj/en/council/meeting-logs/20110308-summary.txt * GLEP 48 (QA) After a long discussion and a review of the final proposal text, the result is the following: - vote: in favor: scarabeus, ferringb, wired, jmbsvicetto didn't state (abstain): betelgeuse, patrick, a3li -> Given the result, the GLEP update is accepted and can proceed, albeit Peteri raised a question how Devrel is going to work out the resolution after the process is handled over from QA. It was agreed that the part of the text (last sentence of the diff) will be updated with string based on what those two teams agree with without more council involvment (unless required otherwise).. http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt * GLEP48 review Jorge submitted a proposal to the ml to update GLEP48[4]. After some initial debate over the power granted to the QA team, the timeline in case of an escalation to DevRel, the relation with DevRel and whether QA should only enforce policies or also take part in creating policies, after the request by Patrick, Jorge -> suggested pushing this back to the mls. Petteri then asked the council to at least vote to commit the non suspension related parts of the proposal. The diff[5] was approved with 6 yes votes. Alec during this discussion presented some thoughts about the QA team[6]. [4] - http://archives.gentoo.org/gentoo-project/msg_ac161677a6e06a8647e16420eeae8d47.xml [5] - http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/glep/glep-0048.txt?r1=1.3&r2=1.4 [6] - http://pastebin.com/C1jGF1DJ > It may sound crazy, but it isn't entirely impossible that decisions > made in the past were not made lightly. This assumes that the decisions have voted against the matter; however, they voted for this matter on the basis of a small change to be made to it (20110308-summary.txt) but that never happened and seems forgotten. Some developers even refer to Diego having used this power in the past. > It's also not entirely impossible that one of the reasons such > decisions are made is so that people can stop rehashing the same > topics over and over again and focus on more useful and fun topics. This assumes the topic to be useless or boring; however, that's personal opinion and there is an useful need for this from the QA, Council and ComRel perspective. Sometimes we need to deal with a more serious topic. This is one of those days. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sat, Jan 18, 2014 at 9:02 PM, William Hubbs wrote: > All, > > I would like to bring back for discussion an old patch to glep 48 [1] > which was suggested by Jorge [2]. > > That patch evolved into this one [3], and in the council meeting back > then [4], parts of it made their way into glep 48, but the rest seemed to > be forgotten. > > Attached you will find an updated version of this patch taking into > account the current version of glep 48. > > This is nothing new; the qa team has requested that commit rights be > suspended before. I am just proposing that we actually add the parts of > the old patch to the glep that spell out when and how this can happen. > > Thoughts? > We almost never suspend commit rights. I'm not really finding a situation where this is necessary. Certainly not in the streamlined fashion proposed here. -A > > William > > [1] http://wiki.gentoo.org/wiki/GLEP:48 > [2] > http://archives.gentoo.org/gentoo-project/msg_ac161677a6e06a8647e16420eeae8d47.xml > [3] http://www.mail-archive.com/gentoo-qa@lists.gentoo.org/msg00144.html > [4] > http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt >
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sun, Jan 19, 2014 at 6:01 PM, Tom Wijsman wrote: > It is more of a "Do we want QA to delegate this through ComRel or not?". Actually, no. What it is is a "Subject was thoroughly discussed in the past, and a decision was made." More than once, in fact. What basis do you have that would warrant more bilkeshedding on this subject? It may sound crazy, but it isn't entirely impossible that decisions made in the past were not made lightly. It's also not entirely impossible that one of the reasons such decisions are made is so that people can stop rehashing the same topics over and over again and focus on more useful and fun topics. Denis.
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sun, 19 Jan 2014 13:46:01 +0100 hasufell wrote: > > either the QA lead or two members of the QA team can require the > > Infra team to temporarily suspend commit access for the developer > > -1 to that part > > That sounds like you are able to make non-trivial decisions without > the approval of the lead. For non-trivial decisions, two members is indeed a bit low; it is probably made in the time of a smaller team, as increasing the amount would beat its purpose (for in case lead is absent) it sounds like "or two members of the QA team" should just be removed. (For trivial decisions, this is in place to deal with extreme breakage.) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sun, 19 Jan 2014 13:22:07 -0700 Denis Dupeyron wrote: > On Sat, Jan 18, 2014 at 10:02 PM, William Hubbs > wrote: > > This is nothing new; the qa team has requested that commit rights be > > suspended before. I am just proposing that we actually add the > > parts of the old patch to the glep that spell out when and how this > > can happen. > > > > Thoughts? > > Yes, thoughts, absolutely. Asking for QA to be at the same time judge, > party and executioner. Need I say more? That is under the assumption that such suspension is permanent as well as that QA is the only judge. However, most mentioned suspensions there are temporary and QA needs to bring forward reasoning as to why QA has requested the temporary suspension; the final judge here is the Gentoo Council just like with ComRel's suspensions. QA really is just a party here and has nearly no final power when it comes to judging or execution; the goal here is to deal with the rather unusual bigger breakages, but if this doesn't go through QA can just forward the request to ComRel and have them consider and do it. This patch just came up by a hypothetical discussion where QA was given the impression that QA has the power to request this; some of the Council meetings back in history seem to approve this patch, others do not. It's a rather odd history, and hence we set things straight here. It is more of a "Do we want QA to delegate this through ComRel or not?". -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sat, Jan 18, 2014 at 10:02 PM, William Hubbs wrote: > This is nothing new; the qa team has requested that commit rights be > suspended before. I am just proposing that we actually add the parts of > the old patch to the glep that spell out when and how this can happen. > > Thoughts? Yes, thoughts, absolutely. Asking for QA to be at the same time judge, party and executioner. Need I say more? Denis.
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
> either the QA lead or two members of the QA team can require the Infra team > to temporarily suspend commit access for the developer -1 to that part That sounds like you are able to make non-trivial decisions without the approval of the lead.
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
All, I put this on the wrong list, so please disregard this here and reply on -project instead; I forwarded this msg over there. Thanks, William signature.asc Description: Digital signature
[gentoo-dev] rfc: formally allow qa to suspend commit rights
All, I would like to bring back for discussion an old patch to glep 48 [1] which was suggested by Jorge [2]. That patch evolved into this one [3], and in the council meeting back then [4], parts of it made their way into glep 48, but the rest seemed to be forgotten. Attached you will find an updated version of this patch taking into account the current version of glep 48. This is nothing new; the qa team has requested that commit rights be suspended before. I am just proposing that we actually add the parts of the old patch to the glep that spell out when and how this can happen. Thoughts? William [1] http://wiki.gentoo.org/wiki/GLEP:48 [2] http://archives.gentoo.org/gentoo-project/msg_ac161677a6e06a8647e16420eeae8d47.xml [3] http://www.mail-archive.com/gentoo-qa@lists.gentoo.org/msg00144.html [4] http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt diff --git a/GLEP:48.mw b/GLEP:48.mw index 1012011..a1633d7 100644 --- a/GLEP:48.mw +++ b/GLEP:48.mw @@ -24,13 +24,15 @@ The QA team should be given certain abilities to look out for the best interests * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action. * The QA team is directed by a lead, chosen yearly by private or public election among the members of the team, and confirmed by the council. The QA team lead can choose one member as a deputy. The deputy has all of his powers directly delegated from the QA team lead and thus his actions and decisions should be considered equal to those of the QA team lead. The deputy is directly responsible only to the QA team lead. * The QA team lead must approve developers who would like to join the project. The applicant must demonstrate a thorough understanding of the duties he would like to perform. By accepting the applicant the QA team lead will accept the responsibility to direct them as part of the team and will be held responsible for any action the team member takes on behalf of the QA team. +* Any QA team lead decision can be revoked by major opposing vote from all current QA members. Given the nature of this action new elections should be held within 1 month to elect a new QA team lead. * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. The QA team does not want to override the maintainer's wishes by default, but only wish to do so when the team finds it is in the best interest of users and fellow developers to have the issue addressed as soon as possible. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. Coding style issues fall under this category, and while they are not severe, they can make automated checks of the tree more difficult. * There will be cases when our tools are incapable of handling a certain situation and policy must be broken in order to get something working completely. This will hopefully not occur very often, but each time it does occur, the QA team and the maintainer will come to some agreement on an interim solution and it is expected that a bug will be opened with the appropriate team to work towards a correct solution. * In the case of disagreement among QA members the majority of established QA members must agree with the action. Some examples of disagreements are whether the perceived problem violates the policy or whether the solution makes the situation worse. * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation. -* If a particular developer persistently causes breakage, the QA team may request that Comrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to Comrel. +* In case a particular developer persistently causes breakage, the QA lead may request commit rights of that developer to be suspended by the Infra team. Comrel should then proceed to evaluate the situation, by finding a compromise or pernamently revoking those rights. +* Should a situation arise where a developer causes breakage to the point that it cannot be ascribed to an honest mistake, either the QA lead or two members of the QA team can require the Infra team to temporarily suspend commit access for the developer, pending analysis of the causes and resolution to be provided by the QA team within 14 days of said suspension. Resolution for these kinds of issues is completely in the hands of the QA team, and only the Gentoo Council can revisit the case. * The
