Closed Bug 561952 Opened 14 years ago Closed 14 years ago

upgrade to L3

Categories

(mozilla.org :: Repository Account Requests, task)

Product:
mozilla.org
Component:
Repository Account Requests
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: gal, Assigned: jlaz)

Details

(Whiteboard: sr) 

Please upgrade my account to L3. My ssh key is already in the system.
For level 3 access, need two vouchers + SR to vouch for you. We already have your form and SSH key on file, so only the vouchers are needed.
(In reply to comment #1)
> For level 3 access, need two vouchers + SR to vouch for you.

Should have been "two vouchers + one SR" (see http://www.mozilla.org/hacking/committer/ for full details). The two vouchers need to each be module owners/peers.
For the record, I have committed 1449 patches over the last two years, and most of them are in our shipped products. Having to fill out this paperwork after the fact in order to keep my access to tracemonkey and nanojit-central, with a precise count of vouchers of module owners and SRs, seems really ... well pointless. Sometimes if a policy doesn't match reality well, its simply not a good policy.
You filed this bug to get your access upgraded to level 3. I'm providing you the information you need in order to fulfill this request, as per the current policy.

If you have a problem with the policy itself, I recommend that you start a new thread on mozilla.governance where the policy makers will actually see it and can discuss it.
I will do that.
SR=mconnor
Whiteboard: sr
Andreas: you are right that it seems strange. What has happened, if you like, is that your level of access to our trees has not kept pace with your importance to the project :-) On the other hand, I would expect the process of you getting the rubber stamps to take about five minutes of you asking people on IRC, so I hope it won't be too burdensome!

(BTW, is that cool Hg tech which allows you to know that you've made 1449 patches?)

One nit: I would expect people being upgraded a level only to have to provide the _difference_ between the two - in this case, one module owner + SR. It's not supposed to look like someone is being forced to start from scratch again.

We have sr=mconnor; I suspect as soon as brendan wakes up we'll have v/sr/just-get-on-with-it-please=brendan as well, and we're done. Unless someone else gets here first.

Gerv
(In reply to comment #7)
>
> (BTW, is that cool Hg tech which allows you to know that you've made 1449
> patches?)

$ hg log | grep -c "Andreas Gal"
1449
vouch=me, over to server-ops for the bump to level 3.
Assignee: marcia → server-ops
Assignee: server-ops → jlazaro
scm_level_3 bit enabled

-jlazaro
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
FWIW, I don't think the policy is broken. You getting two people to comment in a bug is hardly an unreasonable burden given your contributions.

The actual problem is the fact that your ability to do work was interrupted suddenly and without warning, due to the policy implementation changes. That could have undoubtedly been handled better, but it's not a problem with the policy itself.
I absolute do think the policy is broken. The paperwork in this bug is completely pointless bureaucracy. My access was restored based on two vouchers, neither of which are intimately familiar with my work. What did we win by doing this little voucher dance? Did it make my past contributions better/safer? No. Will it make my future contributions better/safer? No.

I completely agree that its not bothersome at all to get rubber stamps. What I disagree with so vocally is _rubber stamps_. If a policy requires someone to get rubber stamps, and those rubber stamps are easy to get, whats the point?
Brendan has also suggested that the SR requirement isn't adding much here and that we should reevaluate SR involvement in the commit access process across the board.  I've got that on the list of items to tackle.  (It didn't come up in the discussions about access policy before, so it wasn't addressed in this revision.)  It's quite possible that in your case this is a rubber stamp because you've been so deeply involved in the project for a good while now, so maybe the rubber-stamp aspect is not be the case for people coming to the project.  It's also possible that all SR involvement in push access decisions is a rubber - stamp.

Agree that anything that is a rubber-stamp is not adding value.    I see Brendan's point that the SR requirement may not be adding much here.  I'm not quite ready to lead that discussion yet, as I think it gets to the broader questions of (a) the overall role of SRs; and (b) what mechanisms should we use to protect / improve code quality.  And we need that discussion to have the right people participating, and in a positive way.
The fact that the vouchers were "rubber stamps" in your case is a result of the fact that you have been around for a long time, and should have requested level 3 access a long time ago. I would not have vouched for someone whose work I hadn't seen, and that I hadn't interacted with on IRC the way I have with you. Your situation is certainly not reflective of the typical process.

We need an objective bar that we can hold people to, and I don't think it's too much to ask that evidence of that bar being met is recorded in a bug. What would you suggest as a concrete change to the policy? Adding "... or has been in the JS team for a few years, regularly hangs out with Brendan, and has submitted 1190 patches" to our criteria might make things smoother for the theoretical future-gal who happens to be hit by an unfortunately-timed technical change, but I don't think that's something we really need to optimize for to be honest!
Gavin, you are not an SR. This is not the place. And your second paragraph in comment 14 obnoxiously puts forth a false dilemma.

Not revoking push access is *not* a failure to optimize. It's a mistake (honest one). What happened in the aftermath, with wannabe-gauleiters jumping to defend process and policy against all reason, is worse.

As Mitchell noted, we are going to revisit the L3 policy, and probably SR, shortly. In the mean time, let's give this bug a rest, it's resolved.

/be
(In reply to comment #15)
> Not revoking push access is *not* a failure to optimize. It's a mistake 

Strike that first "Not", of course.

/be
(In reply to comment #15)
> Gavin, you are not an SR. This is not the place. And your second paragraph in
> comment 14 obnoxiously puts forth a false dilemma.

The policy requires two vouchers and one SR. As I understood it, gal only had one voucher - I acted as second, mconnor as SR. But that's not important.

> revoking push access is *not* a failure to optimize. It's a mistake
> (honest one).

I don't see why the distinction is important...

> What happened in the aftermath, with wannabe-gauleiters jumping to defend
> process and policy against all reason, is worse.

This is a mischaracterization. I had no objection to gal's access being restored immediately and without hoop-jumping, given the circumstances, and I tried to make that happen. It's the suggestion that we need to make adjustments to the policy or process to address this exceptional circumstance that bothered me. There may be other good reasons to make adjustments, but I don't think this is one of them.
(In reply to comment #17)
> There may be other good reasons to make adjustments, but I don't think this
> is one of them.

Why not? Data counts more than theory.

Ed Smith also lost access, and that's not an isolated or unknown "other reason". Everyone else at Adobe who can currently push into nanojit-central lost access too, AFAIK.

Yet we've been shipping nanojit in two major Firefox releases.

This combination of facts alone should give you pause, as a rational being :-). Instead it seems to me you are assuming policy is valid and sound (not merely that it is policy and must be followed or changed).

But the policy is not necessarily valid or sound, and here we are in the aftermath of a mistake that exposed multiple instances of evidence to the contrary.

Are there cases where the SR+two-vouchers has saved us from a bad actor? I don't know of any.

It's hard to weigh pros and cons with only cons in hand. I've mailed the SRs and a few others about this to get more opinions. This will end up in the newsgroups again. In the mean time, tracemonkey and nanojit are L2 and staying at L2, so the policy is not quite being observed (these repos host modules built into Firefox; OTOH so do upstreams such as Cairo).

I'll post a newsgroup link in this resolved bug when there's a newsgroup post.

/be

P.S. The "process over people" attitude I've been decrying lately is evident to many, not just to those who lost access unexpectedly. It's a problem in its own right. I'll leave it alone here, after one more entreaty to pay attention to it.
(In reply to comment #18)
> Ed Smith also lost access, and that's not an isolated or unknown "other
> reason". Everyone else at Adobe who can currently push into nanojit-central
> lost access too, AFAIK.

Yeah, that's also a problem. As far as I know, Gerv has been trying to address fallout from the changes (and we reverted tamarin to level 2 to mitigate).

> Are there cases where the SR+two-vouchers has saved us from a bad actor? I
> don't know of any.

How would we know? We've only ever had more onerous policies (in my history with the project, anyways), so there are no previous less restrictive policies that we can say were "good enough". The enforcement of our policies may have been effective in dissuading bad actors from attempting to gain access - but I don't want to get too caught up in boogey-man scenarios :)

> P.S. The "process over people" attitude I've been decrying lately is evident
> to many, not just to those who lost access unexpectedly. It's a problem in
> its own right. I'll leave it alone here, after one more entreaty to pay
> attention to it.

I think we're on the same side, here. I'm no fan of process for process' (or policy for policy's) sake - far from it. It's one of the main reasons I got involved with dealing with account requests, in fact.
(In reply to comment #19)
> > Are there cases where the SR+two-vouchers has saved us from a bad actor? I
> > don't know of any.
> 
> How would we know? We've only ever had more onerous policies (in my history
> with the project, anyways), so there are no previous less restrictive policies
> that we can say were "good enough".

We are moving to less restrictive on the push-access side over time, to match the way DVCSes work. This means better ongoing code review, static analysis, and automated testing, or a bad patch could come in from anyone.

> The enforcement of our policies may have
> been effective in dissuading bad actors from attempting to gain access - but I
> don't want to get too caught up in boogey-man scenarios :)

(Argumentum ad Ignorantiam, don't do it ;-)

> > P.S. The "process over people" attitude I've been decrying lately is evident
> > to many, not just to those who lost access unexpectedly. It's a problem in
> > its own right. I'll leave it alone here, after one more entreaty to pay
> > attention to it.
> 
> I think we're on the same side, here. I'm no fan of process for process' (or
> policy for policy's) sake - far from it. It's one of the main reasons I got
> involved with dealing with account requests, in fact.

Glad to hear it. What's striking to me is, knowing there was a mistake and people had a loss of access that was unexpected, unintended, and inconvenient (not to say off-putting), too many folks seem to over-sell and over-cite the policy and enforcement of it as maximum goods.

These "policy, yay!" sentiments aren't valid excuses for an error, and if the policy and its application are such blessings (I've already agreed that impartial enforcement is a good thing), they don't need such aggro championing in the face of completely understandable dismay at what happened.

That's what I meant by "process over people" attitude.

/be
Component: Account Request: Hg → Repository Account Requests
QA Contact: hg-acct-req → repo-acct-req
You need to log in before you can comment on or make changes to this bug.