572875 - wtf: remote: Your mercurial account has been disabled due to inactivity.

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: Account Requests, task)

Description

[Robert Sayre]

sayrer:mozilla-central sayrer$ hg push -r default
remote: Your mercurial account has been disabled due to inactivity.
remote: Please file a bug at https://bugzilla.mozilla.org (or http://tinyurl.com/yjopalp) to re-activate your account.
abort: no suitable response from remote hg!

Comment 1

[Robert Sayre]

trying to push a patch for 3.6.4 here... this is a most inopportune time for this!

Comment 2

[Justin Lazaro [:jlaz] (use needinfo)]

hg bit re-enabled

-jlazaro

Comment 3

[Robert Sayre]

(In reply to comment #2)
> hg bit re-enabled

why did it get flipped?

Comment 4

[Justin Lazaro [:jlaz] (use needinfo)]

Not exactly sure, has your account been inactive for some time?

Comment 5

[matthew zeier [:mrz]]

@sayre - was an automated script that, IIRC, pulled from logs to get an idea of account activity.

Comment 6

[Robert Sayre]

(In reply to comment #4)
> Not exactly sure, has your account been inactive for some time?

My previous push to mozilla-central was

Sun Jun 06 12:08:23 2010 -0700

seems like a pretty overzealous script.

Comment 7

[Aravind Gottipati [:aravind]]

(In reply to comment #6)
> My previous push to mozilla-central was
> 
> Sun Jun 06 12:08:23 2010 -0700
> 
> seems like a pretty overzealous script.

I apologize that your account was disabled, but in https://bugzilla.mozilla.org/show_bug.cgi?id=560875#c6 you said you used [e-mail] as your primary Hg account/email.

So we disabled the Hg access to your other mercurial account ([e-mail]).  Apparently, you still use your mozilla.com e-mail address for accessing the server, but you use [e-mail] as your username in mercurial (what shows up in hg log, etc..).

Could you please make our lives easier by picking one account?  If it means that we create another account for you in ldap and transfer your (existing) privileges to it, thats fine by me, but it should help avoiding problems like this in the future.

Comment 8

[Mike Shaver (:shaver emeritus)]

We should be logging pushes, not hg log attribution: people who mostly push other people's patches won't show up at all otherwise.

Comment 9

[Robert Sayre]

(In reply to comment #7)
> 
> Could you please make our lives easier by picking one account?  If it means
> that we create another account for you in ldap and transfer your (existing)
> privileges to it, thats fine by me, but it should help avoiding problems like
> this in the future.

I have two because IT switched my account to [e-mail] for hg access when they switched to LDAP. I was unhappy about that at the time, but it was evidently impossible at the time. If things have changed, and I can use [e-mail] to push to hg, that would be great.

Comment 10

[Aravind Gottipati [:aravind]]

(In reply to comment #8)
> We should be logging pushes, not hg log attribution: people who mostly push
> other people's patches won't show up at all otherwise.

I do log pushes and that is how I look for account activity, that message is just the default message for anyone whose account is disabled (I don't have an easy way to detect/display why it was disabled).

Hg access for [e-mail] account was disabled per 560875, The lists in that bug were probably generated by looking at log messages.

@sayrer: I will create an account for you and transfer your privileges to it.  Not sure why we told you it wasn't possible, but it definitely is now.

Comment 11

[Reed Loden [:reed]]

(In reply to comment #10)
> Hg access for [e-mail] account was disabled per 560875, The lists in
> that bug were probably generated by looking at log messages.

Bug 560875, comment #9 says that sayrer should have been removed from the list before processing. Is there a reason why that wasn't done?

> @sayrer: I will create an account for you and transfer your privileges to it. 
> Not sure why we told you it wasn't possible, but it definitely is now.

Duplicate LDAP accounts for people seems like a very bad idea, which is why they generally were frowned upon during the initial CVS-to-Hg migration. You end up with two separate SSH key lists to maintain in LDAP, which increases the chance that mistakes are made or things are forgotten. Also, when people leave MoCo or the project itself, having multiple accounts makes it way more difficult to ensure access is terminated correctly. Duplicate accounts create way more work on IT and give little-to-no benefit to an outside user.

Comment 12

[Brendan Eich [:brendan]]

Reed: sayrer had access before he was hired by Mozilla ("MoCo" is an annoying and counter-productive abbreviation for a wholly-owned subsidiary that is an artifact of annoying tax laws -- use "Mozilla" to avoid trouble). Why wouldn't he keep it in the event he left his employment relationship?

AFAIK I'm still [e-mail]. Mitchell remained [e-mail] when Netscape/AOL laid her off in 2001.

/be

Comment 13

[Reed Loden [:reed]]

(In reply to comment #12)
> Reed: sayrer had access before he was hired by Mozilla ("MoCo" is an annoying
> and counter-productive abbreviation for a wholly-owned subsidiary that is an
> artifact of annoying tax laws -- use "Mozilla" to avoid trouble). Why wouldn't
> he keep it in the event he left his employment relationship?

I was referring to committers in general and not to sayrer specifically. MoCo's termination procedures should allow for people who are remaining with the project to have any commit-type access migrated to a personal LDAP account at that point.

> AFAIK I'm still [e-mail]. Mitchell remained [e-mail]
> when Netscape/AOL laid her off in 2001.

You commit as [e-mail], though.

This discussion is just a rehash of sayrer's complaining in bug 388594. As dbaron rightfully pointed out in bug 388594, comment #24, Hg allows you to specify the e-mail address your commits use when being displayed (via your .hgrc). Only the underlying pushlog db will actually show the LDAP account being used for committing.

Comment 14

[Brendan Eich [:brendan]]

(In reply to comment #13)
> (In reply to comment #12)
> > Reed: sayrer had access before he was hired by Mozilla ("MoCo" is an annoying
> > and counter-productive abbreviation for a wholly-owned subsidiary that is an
> > artifact of annoying tax laws -- use "Mozilla" to avoid trouble). Why wouldn't
> > he keep it in the event he left his employment relationship?
> 
> I was referring to committers in general and not to sayrer specifically. MoCo's
> termination procedures should allow for people who are remaining with the
> project to have any commit-type access migrated to a personal LDAP account at
> that point.

Keep writing MoCo and spouting policy details that are not relevant to Mozilla contributors in general, and I'll quit and put your words to the test, and we'll see what happens.

Your tone and approach here and previously (we've talked) are relentleessly bureaucratic and off-putting. We're not arguing about what is, but about what should be.

> > AFAIK I'm still [e-mail]. Mitchell remained [e-mail]
> > when Netscape/AOL laid her off in 2001.
> 
> You commit as [e-mail], though.

That's not how I committed to CVS for over a decade; it's either a (minor but not insignificant) mistake, or an irrelevant implementation detail.

> This discussion is just a rehash of sayrer's complaining in bug 388594.

No.

> As dbaron rightfully pointed out in bug 388594, comment #24, Hg allows you to
> specify the e-mail address your commits use when being displayed (via your
> .hgrc). Only the underlying pushlog db will actually show the LDAP account
> being used for committing.

Wrong again -- this argument is not about push message contents in any way, shape, or form.

LDAP entries are needed for many contributors, not only for Mozilla employees. In principle, there is no good reason that I can't be [e-mail] and sayrer can't be [e-mail]. If hiring by Mozilla entails another entry, so be it. We'll have to risk the duplicated keys, or use an LDAP feature that equates two email addresses to one account, or find another implementation-detail solution.

/be

Comment 15

[Brendan Eich [:brendan]]

(In reply to comment #14)
> We're not arguing about what is, but about what should be.

Or: we're not arguing *only* about what is, but *also* about what should be.

Something went wrong here. Sayrer should not have lost access. You can blame someeone else for not revoking one of sayrer's ids before enabling the other, or something (Igor Bukanov had the same problem, AFAICT).

I'm suggesting strongly that we don't blame people for failing to follow over-complicated rules that serve a limited view of LDAP and Mozilla contributor identity.

We have many long-term contributors. Who they work for is not as important as their standing in the Mozilla community. Especially if they started contributing with a well-known id (email address) and want to keep using it while employed.

/be

Comment 16

[Brendan Eich [:brendan]]

(In reply to comment #15)
> We have many long-term contributors. Who they work for is not as important as
> their standing in the Mozilla community. Especially if they started
> contributing with a well-known id (email address) and want to keep using it
> while employed.


So (sorry for multiple comments), our systems should reflect the long-standing identities and relationships. Tools should serve people, people should not be id- and paper-shuffling servants of poor tools. I'm a broken record on this.

/be

Comment 17

[Gervase Markham [:gerv]]

I apologise to sayrer for the inconvenience caused. It looks like one of the comments in the original bug, stating that various email addresses of his should not be disabled at all, were missed or misunderstood.

I entirely agree with brendan that the technology should serve the people. But if LDAP uses the email address as the equivalent of a GUID for an account, I can see it would be difficult to have more than one per account. And I can also see it can cause trouble to have multiple accounts for the same person.

I'm sure sayrer and IT can work out how best to arrange his accounts giving existing technical limitations. :-)

I guess it was too much to hope that this process could have gone entirely without a hitch, but this seems to be the only problem so far... (famous last words)

Gerv

Comment 18

[Brendan Eich [:brendan]]

Igor had the same problem.

Is LDAP really incapable of having secondary keys or aliases? I forget what I used to know of it from Netscape. But Aravind in comment 10 says he can cope, if I'm reading him right.

/be

Comment 19

[Aravind Gottipati [:aravind]]

(In reply to comment #18)
> Is LDAP really incapable of having secondary keys or aliases? I forget what I
> used to know of it from Netscape. But Aravind in comment 10 says he can cope,
> if I'm reading him right.

We can handle multiple accounts just fine.  I should have a second account ready for sayrer today.

> You can blame someeone else for not revoking one of sayrer's ids before 
> enabling the other,or something (Igor Bukanov had the same problem, AFAICT).

That would be me, I assumed he was using the [e-mail] (which didn't exist) to push, and disabled the [e-mail] account.  Since it was a manual process, I only looked at commit messages and took them at face value.  The current (automated) process looks at the actual ldap query logs to figure this part out, and so far hasn't had any false positives.

> We have many long-term contributors. Who they work for is not as important as
> their standing in the Mozilla community. Especially if they started
> contributing with a well-known id (email address) and want to keep using it
> while employed.

This has always been by interpretation when I enforced the policy.  Specifically this is what I tell people, "if you have been a community contributor before joining Mozilla, its perfectly fine for you to keep your community account and add privileges to it.  However, if you are gaining privileges because you are employed with moco, then I have to grant them to your moco account".

Comment 20

[Aravind Gottipati [:aravind]]

@sayrer: you should have an e-mail from me with your LDAP account information.  It currently has the same public key as your mozilla.com account.  Please use it to check in to Hg, and let me know if you run into problems.  

Once you confirm that its working, please let us know, so we can revoke access from the moco account.