Accessing the list of contributors with L1 and L3 access

RESOLVED FIXED

Status

Infrastructure & Operations
Infrastructure: Other
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: jdm, Assigned: jabba)

Tracking

(Blocks: 1 bug)

Details

(Reporter)

Description

6 years ago
I'm a steward for the Coding functional area, so I receive emails from potential new contributors. I am interested in determining how many of those people who email end up receiving various levels of commit access, so presumably I would need to correlate email addresses with LDAP accounts or something. Is this something I can do? Some kind of web service would be lovely (maybe protected by LDAP?), but the bare minimum I would need is a text file containing the email address and level of commit access present. This is something I want to do on a monthly basis, so some kind of service would be a lot easier from my point of view.
Assignee: server-ops → server-ops-infra
Component: Server Operations → Server Operations: Infrastructure
I don't think there are many/any privacy concerns with publishing a list of LDAP accounts that have scm_level_* commit access, since for the most part people using that commit access are already publishing their addresses on tbpl. Seems like something that should be relatively simple to do in a cron job and put behind LDAP auth on the web somewhere.
(Assignee)

Updated

5 years ago
Assignee: server-ops-infra → jdow
(Assignee)

Comment 2

5 years ago
So, only community committers, not employees? And do I need to filter out accounts that perhaps used to have commit access but no longer do for some reason? What about people that still have accounts, but have been inactive for 6 months?

For ease of use and low overhead I'd say I can start with an LDAP query that runs on a cronjob and just e-mails the result to a distribution list that I can put you (and anyone else that wants it) on. How would that sound?
I don't think there's any need to filter employees/contributors separately. The other edge cases you mention probably don't matter much either - the underlying goal is to get a list of people who currently can commit (and which level repository they can commit to).
(Assignee)

Comment 4

5 years ago
Ok, so the way that the data is stored in LDAP, I can do:

1) simple query of members of scm_level_1
This would include all members of that group, whether the actual accounts still exist, are disabled, are current or not, employees and contributors alike. Also this would include scm_level_2 and scm_level_3, since the higher levels require the lower levels, this is probably wanted though

2) complex query to find active contributors
Basically one query to get the members of scm_level_1 and then an additional query for each member to test if a) they actually exist still, b) if they have hgAccessEnabled=TRUE (this is the flag that gets set to false after 6 months of inactivity)

3) even more complex query to include svn committers as well
Since these aren't necessarily part of any scm_level_* groups, the query would be more of a "return all users that have either svnAccountEnabled=TRUE, svnAccountEnabled=FALSE, hgAccountEnabled=TRUE, hgAccountEnabled=FALSE as well as the bzrAccountEnabled=TRUE or FALSE, etc. to find all users that have or had commit rights at one time, and again, this could be further filtered to just include accounts that currently have commit rights, excluding expired ones due to inactivity.

For any of them I can filter out moco employees, mofo employees as needed and do the same for scm_level_2 and _3 as needed.

Would the distribution list and a cronjob-generated e-mail suffice, or would it be preferable to have it on a webpage that can be viewed?

If the distribution list is good, let me know who should be on it. If the webpage is preferred, I'll have to find a spot to host it (shouldn't be too hard) and need to know if that page would need to be behind LDAP auth. I might have to ask for OpSec to give the greenlight if it shouldn't be behind auth.

(sorry for all the questions!) :-)
(Reporter)

Comment 5

5 years ago
For my purposes, the simple query with no filtering works just fine. I think the webpage would be easier to consume than an email.
(Reporter)

Comment 6

5 years ago
And I would be ok with it being stored behind LDAP, assuming that non-employee LDAP accounts could access it.
(Assignee)

Comment 7

5 years ago
Alright, I kept it mostly simple. After some internal discussions, we decided to filter out any disabled accounts from this list, but not simply expired accounts. I wrote a script that will generate a list of all members of all three scm_level groups and sort them alphabetically, dump to a .txt file, and a simple index.html which shows the time at which they were generated. I set a cron job to have this run at 5am every day.

https://ldap.mozilla.org/contributors

It's behind LDAP auth, but anybody with an LDAP account should be able to log in, i.e. it's not restricted to any single group or employees only.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Component: Server Operations: Infrastructure → Infrastructure: Other
Product: mozilla.org → Infrastructure & Operations
(Reporter)

Updated

5 years ago
Blocks: 652719
You need to log in before you can comment on or make changes to this bug.