782558 - commit access level 3 for bhavana bajaj

Status: RESOLVED FIXED

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

Description

[bhavana bajaj [:bajaj]]

Attachment: contains users public key

login name : [e-mail]

Comment 1

[bhavana bajaj [:bajaj]]

Committers agreement sent.

Comment 2

[Marcia Knous [:marcia]]

Adding Shannon to confirm the form.

Bhavana: Level 3 will require two vouchers - module owners or peers of code stored at this level to post in this bug.

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

For this bug, we should add Release Management to https://wiki.mozilla.org/Commit_Policy:Current_Procedures under its own module and require a different vouching policy.  Bhavana doesn't need level 3 because she is going to commit code to the core components of the project but as a Release Manager she will be called upon to do branching and merging on repos we release Firefox products from. 

In the /build team we were required to get two vouchers from existing members of our own team, trusting that they were senior enough (and not just handing out vouches like candy) to know that the new addition is aware of what responsibility comes with this power.  Release Management is a small team but we do have two people with enough seniority and experience at Mozilla, regularly dealing with sensitive information and with things that could really mess up MILLIONS of people, that we could vouch for her and take on the risk of adding Bhavana to our level 3 committers.

Neither Alex nor myself are module owners of peers of code but we both have level 3 access and we should be able to vet a new Release Manager to ensure they can be trusted with this level of commit privileges.

Comment 4

[Alex Keybl [:akeybl]]

Yep, I vouch for Bhavana as well. If not, Gavin/Dolske should be able to vouch.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Lukas Blakk [:lsblakk] from comment #3)
> For this bug, we should add Release Management to
> https://wiki.mozilla.org/Commit_Policy:Current_Procedures under its own
> module and require a different vouching policy.

As it says at the top of that page, and has since July 2010, those procedures are no longer used.

> In the /build team we were required to get two vouchers from existing
> members of our own team, trusting that they were senior enough (and not just
> handing out vouches like candy) to know that the new addition is aware of
> what responsibility comes with this power.  Release Management is a small
> team but we do have two people with enough seniority and experience at
> Mozilla, regularly dealing with sensitive information and with things that
> could really mess up MILLIONS of people, that we could vouch for her and
> take on the risk of adding Bhavana to our level 3 committers.

For build/ maybe that's how it worked.  But the releng people who have level 3 commit access went through the normal process and were vouched for by peers/owners of code stored at L3 (e.g. Bug 679146, 733033).  The release management people with L3 access have also gone through the normal process (e.g. Bug 618931).

The rest of this paragraph is an argument for a policy change that should be proposed and agreed to on .governance, not in this bug.

> Neither Alex nor myself are module owners of peers of code but we both have
> level 3 access and we should be able to vet a new Release Manager to ensure
> they can be trusted with this level of commit privileges.

This is also an argument for a policy change, and belongs on .governance.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Alex Keybl [:akeybl] from comment #4)
> Yep, I vouch for Bhavana as well. If not, Gavin/Dolske should be able to
> vouch.

You are not a module owner or peer of code stored at level 3, so per the existing policy you cannot vouch for Bhavana's L3 commit access.

Comment 7

[Alex Keybl [:akeybl]]

Cool, so I'm hoping Gavin/Dolske can vouch :)

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Sometimes it's worth stepping back and seeing whether the policy is serving its goals before applying it too zealously :)

Dolske and I aren't really in a better position to vouch for Bhavana than the people she's working directly with as part of the rel-mgmt team. lsblakk/akeybl may not be formalized "peers" of a level 3 code module, but I trust their judgement in vouching for a colleague for level 3 access.

I think a rough list of the goals of the policy are to ensure that the person requesting access has:
1) demonstrated ability and confidence with the relevant tools (Hg/TBPL/etc.)
2) is trustworthy enough to not abuse the access
3) has built relationships with people who can help should something go wrong

Bhavana clearly has #2 and #3. I'm not sure about #1, but that's only because I haven't worked closely with Bhavana, and so I'm happy to defer to akeybl/lsblakk on that item.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

tl;dr I'll vouch!

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #5)

> For build/ maybe that's how it worked.  But the releng people who have level
> 3 commit access went through the normal process and were vouched for by
> peers/owners of code stored at L3 (e.g. Bug 679146, 733033).  The release
> management people with L3 access have also gone through the normal process
> (e.g. Bug 618931).

See bug 514260 where I was able to get L3 access with only vouching from two RelEng team members who themselves had L3 access, this was not just for build/ repo and they are not module owners or peers of L3 code.

If people want to discuss this further, we can take this to .governance for wider discussions but I actually do just want people to use their judgement and discretion here, recognize that RelMan is now a small team (currently 3 people) that needs to do certain specialized tasks and apply the best decision to this request for the goals of Firefox/Mozilla product releases.  If anything, bug 618931 shows only that since Christian was a solo Release Manager, he had to get vouching from module owners and/or peers so that he could do the work (merge days) that no one else with L3 access wants to take on.  

We still need one more voucher for Bhavana - I can either go twist someone's arm who does not work with her daily to provide a rubber stamp or we can agree that either Alex or I are more qualified to vouch for her and should be able to do so in this instance without a complete policy re-write.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

We're just waiting on Shannon to confirm receipt of Bhavana's form.

Comment 12

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Lukas Blakk [:lsblakk] from comment #10)
> (In reply to Kyle Huey [:khuey] ([e-mail]) from comment #5)
> 
> > For build/ maybe that's how it worked.  But the releng people who have level
> > 3 commit access went through the normal process and were vouched for by
> > peers/owners of code stored at L3 (e.g. Bug 679146, 733033).  The release
> > management people with L3 access have also gone through the normal process
> > (e.g. Bug 618931).
> 
> See bug 514260 where I was able to get L3 access with only vouching from two
> RelEng team members who themselves had L3 access, this was not just for
> build/ repo and they are not module owners or peers of L3 code.

There was no L3 access in 2009 because the policy that created different levels in hg did not exist yet.

Comment 13

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #11)
> We're just waiting on Shannon to confirm receipt of Bhavana's form.

Unless I missed something we're waiting on a second voucher as well.

Comment 14

[Johnathan Nightingale [:johnath]]

Does my vouching help, here? I don't know if I run afoul of reporting chain etiquette, but if Bhavana wants my sword, she has it.

Comment 15

[Justin Dolske [:Dolske]]

v=me just to be extra sure. :)

Comment 16

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

With gavin and dolske vouching we're just waiting for the form.

Comment 17

[[e-mail]]

I have received the form.

Comment 18

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Over to server ops for an l3 powerup.

Comment 19

[Michael Burns [:mburns]]

+scm_level_1, +scm_level_2, +scm_level_3, +sshkey, +hg.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #12)
> There was no L3 access in 2009 because the policy that created different
> levels in hg did not exist yet.

People who had CVS access were automatically granted level 3 access when that switchover happened. (Though FWIW, Aki and Coop are "module peers" by any reasonable sense of the word, regardless of whether we've properly updated the module peers list.)

As I mentioned before, though, haggling over a strict interpretation of the policy isn't really productive, so rather than nitpicking each others interpretation of the policy, let's focus on getting people their required access while following reasonable procedures.

Comment 21

[Alex Keybl [:akeybl]]

(In reply to Michael Burns [:mburns] from comment #19)
> +scm_level_1, +scm_level_2, +scm_level_3, +sshkey, +hg.

Thanks for resolving all! Bhavana will be in charge of the 4/1 merge day :)