Closed Bug 542345 Opened 15 years ago Closed 15 years ago

Hg Account Request - Fabien Cazenave <kaze@kompozer.net>

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kaze, Assigned: sean)

Details

(Whiteboard: ssh-key, voucher1)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.17) Gecko/2010010604 Ubuntu/8.04 (hardy) Firefox/3.0.17 Build Identifier: I would like to get an Hg access to work efficiently with the SeaMonkey team on the Composer (see bugs 477840 and 477845) and possibly on the editor core. I have filed a Committer's agreement form and my SSH2 key is registered. Reproducible: Always
Unless you would somehow not need to: *See all steps at http://www.mozilla.org/hacking/committer/. *See bug 451304 as an example.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Hg Account Request → Hg Account Request - Fabien Cazenave
Whiteboard: ssh-key
For the record, this was a request for c-c [and m-c] push access. He already has svn privs. I vouch for c-c access! Also, if possible can we get him setup with the basic hg perms so he can push to user repo's (so he can work off-trunk for standalone composer; see: http://hg.mozilla.org/users/Callek_gmail.com/kompozer-central/ )
Has agreement per: Bug 513248 c#4
Whiteboard: ssh-key → ssh-key, form, voucher1,
Vouchers must be module owners or peers. It's impossible to grant access to c-c without also granting access to user repos :)
Whiteboard: ssh-key, form, voucher1, → ssh-key, form
(In reply to comment #4) > Vouchers must be module owners or peers. It's impossible to grant access to c-c > without also granting access to user repos :) I am a peer; c-c build system. As far as "impossible to..." I want him to have access to user repo's, but if your cause/effect is reversed I understand. Once he has c-c access I know he will _also_ have user-repo access.
Whiteboard: ssh-key, form → ssh-key, form, voucher1
Hrm, we don't have the new system in place yet where access to e.g. user repos is on a basic level and doesn't need all the process of hg_mozsrc access. And then, the comm-central build system hasn't been entered anywhere officially as a module anywhere, though I as its owner had agreed with dmose that this will be done. Hrm, I guess there's some breakage in our module system. yay! :( I'd basically be willing to vouch for Fabien, but I'd love to have him have hg_mozilla access only for the moment, and only complete the process up to hg_mozsrc once he has more experience of actually working with the process around here, with bugzilla, reviews, checkins, etc. He will end up as the module owner for KompoZer in comm-central, but even getting this in there is just at its early stages right now. Gerv, we have a commit access process dilemma here, do we have some way of navigating out of it?
Giving him hg_mozilla, the basic Hg bit, will give him access to user repos without giving him access to m-c or c-c (which require hg_mozsrc). That is true today. It'll also give him access to all the rest of hg which is not extra-secure. If he wants m-c and c-c access, he'll need the normal 2 vouchers and a super-reviewer. There are no plans to change this. Does that help? Gerv
(In reply to comment #7) > Does that help? I guess the problem is that we don't officially know a process for how to get just hg_mozilla right now - what does he need? One voucher enough? We'd have that...
Getting just hg_mozilla is the same as getting normal non-c-c/m-c hg access. I'm fairly sure we have a process for that, don't we? Gerv
Where would Fabien need access to, if not comm-central/mozilla-central?
(In reply to comment #9) > Getting just hg_mozilla is the same as getting normal non-c-c/m-c hg access. > I'm fairly sure we have a process for that, don't we? Not yet - the first time we would have is when we make your proposals come true. The actual problem we have here is exactly that we don't have a process for non-L10n, non-incubator, non-hg_mozsrc but just plain simple hg access. (In reply to comment #10) > Where would Fabien need access to, if not comm-central/mozilla-central? For the moment, we want him to have access to user repos, esp. the one Callek pointed out in comment #2, where we are trying to get things up to a point where KompoZer can join Mozilla repositories. And we hope that from that work, we'll have Fabien come out with enough experience that we can get hg_mozsrc access for him finally.
(In reply to comment #11) > (In reply to comment #10) > > Where would Fabien need access to, if not comm-central/mozilla-central? > > For the moment, we want him to have access to user repos, esp. the one Callek > pointed out in comment #2, where we are trying to get things up to a point > where KompoZer can join Mozilla repositories. As per prior discussions with both mitchell and gerv, we do not currently have any such policy for user repos-only access.
(In reply to comment #12) > As per prior discussions with both mitchell and gerv, we do not currently have > any such policy for user repos-only access. Indeed not. KaiRo is not seeking user repos-only access for Fabian, he is seeking normal access for Fabian and expecting him to be checking in to the user repos. Important difference. I'm sure there are people who have hg_mozilla and not hg_mozsrc. What process did they follow to get into that state? Fabian should follow that. If there really is no process, then I think a vouch from one module owner should be sufficient. Gerv
Lots of people have hg_mozilla and not hg_mozsrc, namely Labs repo access requests, and similar things. Explicitly for user repos seems tricky, but if we're treating this as equivalent to, say, the TraceMonkey repo, then that makes sense as a parallel.
(In reply to comment #13) > (In reply to comment #12) > > As per prior discussions with both mitchell and gerv, we do not currently have > > any such policy for user repos-only access. > > Indeed not. KaiRo is not seeking user repos-only access for Fabian, he is > seeking normal access for Fabian and expecting him to be checking in to the > user repos. Important difference. Please re-read comment #11 again. > I'm sure there are people who have hg_mozilla and not hg_mozsrc. What process > did they follow to get into that state? Fabian should follow that. They needed access to some other specific repository. As I said in my previous comment, we do not grant accounts for user repos-only access, which is what Fabien is seeking currently, as per my understanding of the above comments.
<sigh> So you are saying that because Fabien doesn't need access to enough repositories, we don't have a process which fits him? Then let's use the process for the next level up. Sure, it might be stronger than any process we may eventually have for user-repo-only access, but that may not prove to be a problem in practice. As Mike says, if Fabien can meet equivalent conditions to those used for Labs or Tracemonkey, then I'm sure we can give him hg_mozilla. Process is supposed to be an enabling tool, not a cluster of caltrops. :-) Gerv
(In reply to comment #16) > <sigh> So you are saying that because Fabien doesn't need access to enough > repositories, we don't have a process which fits him? As per comment #11, he's wanting access to user repos. We do not (and likely are never going to) have a policy for such for various reasons. > Then let's use the process for the next level up. Sure, it might be stronger > than any process we may eventually have for user-repo-only access, but that may > not prove to be a problem in practice. As Mike says, if Fabien can meet > equivalent conditions to those used for Labs or Tracemonkey, then I'm sure we > can give him hg_mozilla. You're really not making sense here. If he wants access to Labs, the labs guys have to vouch. If he wants access to Tracemonkey, the tracemonkey guys have to vouch. ... but he's not wanting access to either of those. Unless there's a specific non-users/ repo that he needs access to, access can't be granted at this time.
(In reply to comment #17) > You're really not making sense here. If he wants access to Labs, the labs guys > have to vouch. If he wants access to Tracemonkey, the tracemonkey guys have to > vouch. ... but he's not wanting access to either of those. Unless there's a > specific non-users/ repo that he needs access to, access can't be granted at > this time. Alt proposal then: Create an incubator/ repo then for this; grant him access per EXISTING rules for incubator and we're set. Just because the repo exists in users/ does not make it much different than incubator except we are cutting out part of the process that IT has to handle if we did; and allowing the repo's easier deletion when it comes time.
(In reply to comment #18) > Alt proposal then: Create an incubator/ repo then for this; grant him access > per EXISTING rules for incubator and we're set. Very well. Policy is at http://www.mozilla.org/hacking/incubator-repository.html. Please start with the "Logistics and Operational Parameters" section first and go with that. If the incubator repo method is indeed the way you wish to go, I will resolve this bug as INCOMPLETE until the repo has been approved and created.
It is NOT the way I wish to go; it is just sad that this can't be resolved. Committer policy is not meant to be a roadblock to progress.(In reply to comment #17) > As per comment #11, he's wanting access to user repos. We do not (and likely > are never going to) have a policy for such for various reasons. > https://wiki.mozilla.org/Commit_Policy#Level_1_-_Try.2FUser.2FIncubator_Access Really indicates there is a CLEAR proposal to making this work
(In reply to comment #16) > <sigh> So you are saying that because Fabien doesn't need access to enough > repositories, we don't have a process which fits him? That's exactly what we have here. Right now it looks like Reed is forcing into creating an official incubator/ repo (we have all needed support for that) instead of going with the poor man's solution of a user repo and getting the required developer access there, just to have some process to follow. IMHO, it's almost ridiculous that we need to apply heavier process that involves much more people just because we don't have a lightweight process in place (yet - because as Callek points out, there is an actual proposal up that would have this process in place).
(In reply to comment #17) > As per comment #11, he's wanting access to user repos. We do not (and likely > are never going to) have a policy for such for various reasons. What "various reasons"? The only reason I've ever seen cited against granting hg_mozilla for user repo access is the one you gave in comment 12 - "gerv and mitchell said we don't have a policy for it". That's not the same thing as "we have a policy against it", and it doesn't preclude us from creating one - looks to me like Gerv's in favor. It makes no sense that Fabien should have an easier time getting access if he said he wanted it "for tracemonkey" or "for labs". If one voucher is satifactory for hg_mozilla, then that should be true regardless of the requestee's intended use of that permission bit.
The delay in implementation of the new policy is technical rather than political. I am entirely happy with Fabien being given hg_mozilla on the basis of the vouch of a module owner (which KaiRo is). This is the current technical equivalent of Level 2 access under the new policy, and will be converted into it by the migration steps I am currently working out with Aravind. Gerv
I stand corrected; KaiRo is not a module owner on http://www.mozilla.org/about/owners.html (which surprises me). If you can find someone who is to vouch for Fabien, he can have hg_mozilla. :-| Unfortunately, there's technically no way yet to give him "user repo only" access, although we hope there will be soon. Gerv
(In reply to comment #24) > I stand corrected; KaiRo is not a module owner on > http://www.mozilla.org/about/owners.html (which surprises me). If you can find > someone who is to vouch for Fabien, he can have hg_mozilla. :-| Unfortunately, > there's technically no way yet to give him "user repo only" access, although we > hope there will be soon. The c-c build system was to be a module on owners.html as of a long time ago, with this bug we just realised it is not (to some fail in system somewhere). KaiRo *is* the module owner of that. With myself, ted, Standard8, and iirc gozer as peers.
(In reply to comment #25) > The c-c build system was to be a module on owners.html as of a long time ago, > with this bug we just realised it is not (to some fail in system somewhere). > > KaiRo *is* the module owner of that. With myself, ted, Standard8, and iirc > gozer as peers. Brendan, is this correct to your knowledge? As per https://wiki.mozilla.org/Module_Owners_Activities_Modules#Governance_Submodule:_Module_Ownership_System, the module ownership team has to approve all new modules, so just want to make sure this is ok with the module-ownership@ group. If it is, I'm happy to create the module in Despot.
To my knowledge, this has never been raised to the module ownership group.
Hmm, I thought we had discussed that quite some time ago in the module ownership group (which I'm part of), but I don't have my mail archives with me this weekend, so I can't check. Dan Mosedale had agreed that we put that module up but this stalled somewhere. It's really interesting what things we discuss in this bug that is just meant to get some low-level access for Fabien. ;-)
(Aside: KaiRo: are you sure you know how the winking smiley is used in English? I've seen you use it in some really weird contexts recently, and it's led to some people being confused about the point you are making.) I'm doing my best to get the new policy signed off and the LDAP changes made (current ETA: 15th Feb). If you manage to find a module owner to vouch for Fabien before then, great. Otherwise I hope to be able to help you better soon. Gerv
(In reply to comment #29) > I'm doing my best to get the new policy signed off and the LDAP changes made > (current ETA: 15th Feb). Is there a bug tracking the LDAP changes?
My understanding is that IT are using bug 524080 to track this work. Gerv
(In reply to comment #26) > (In reply to comment #25) > > The c-c build system was to be a module on owners.html as of a long time ago, > > with this bug we just realised it is not (to some fail in system somewhere). > > > > KaiRo *is* the module owner of that. With myself, ted, Standard8, and iirc > > gozer as peers. > > Brendan, is this correct to your knowledge? As per > https://wiki.mozilla.org/Module_Owners_Activities_Modules#Governance_Submodule:_Module_Ownership_System, > the module ownership team has to approve all new modules, so just want to make > sure this is ok with the module-ownership@ group. If it is, I'm happy to create > the module in Despot. The module has been created and is listed on owners.html now. (In reply to comment #29) > I'm doing my best to get the new policy signed off and the LDAP changes made > (current ETA: 15th Feb). If you manage to find a module owner to vouch for > Fabien before then, great. Me vouching makes a module owner who vouched now, right? So, can we move on with this?
OK, over to IT to create an LDAP account for Fabien, with hg_mozilla only.
Assignee: marcia → server-ops
Summary: Hg Account Request - Fabien Cazenave → Hg Account Request - Fabien Cazenave <kaze@kompozer.net>
Access granted.
Assignee: server-ops → sean
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Argh, I didn't notice that Erica hasn't confirmed receipt of the form. Erica: can you confirm that you have a form on file for Fabien? Callek: please don't touch the whiteboard markers in Account Request bugs.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: ssh-key, form, voucher1 → ssh-key, voucher1
(In reply to comment #3) > Has agreement per: Bug 513248 c#4 Gavin, he *does* have the agreement; which is why I added that whiteboard message.
Erica is the only person who can verify that the agreement is on file.
Gah, I missed the bug reference. <sigh> Sorry for the flip flopping here.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
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.