Description David Williams 2011-09-16 02:57:14 EDT

Short version: 

Anyone inactive in Simultaneous Release aggregation files for the past year will be removed from the access group on 10/14, I propose. 

Long, interesting, entertaining version: 

As most readers of this bugzilla component will know, to commit changes to the yearly, simultaneous "common repo" input files, existing committers need to ask for access, give their project affiliation, and they are pretty much "in" -- and they technically access (write) those files by becoming members of the Linux group named 'callisto-dev'. (It is named that since "callisto" was our first simultaneous release). 

So far, so good. Not too hard. Not much overhead. 

But ... over the years ... over 6 Simultaneous Releases, to be exact ... the list gets very large, and currently there is no process to remove or reduce people. There is no _pressing_ reason to remove people ... but, just seems like a good hygiene to remove anyone no longer involved ... at least have a process to do so every now and then, such as once a year, or so. 

One option is to remove everyone and have them re-apply ... JUST KIDDING! :) 

Here's my proposal ... others welcome. 

I suggest just about this time every year (shortly after SR1) we see who has been active to the current and "past year" Simultaneous Release aggregation ... and have them automatically continue as-is ... but anyone else, in the callisto-dev list, that has not committed anything in the previous year would be removed from the callisto-dev list --- maybe give a chance to say "wait, leave me on the list". 

Sound like a reasonable approach? 

Looking at the cvs change logs, I see that 59 people have committed to "indigo.build" project (or, to the one milestone of "juno.build" project). This goes back to the beginning of Indigo input, August 2010. 

In contrast, there are 109 people in the callisto-dev group.

That leaves 50 people that have not committed to these "input files" since the very beginning of Indigo. 

I suspect of those 50, some are still "involved" in some way, and might want to stay in the list as backup for someone. But, I'd guess, 20 to 40 are no longer involved enough to care. 

So, where to go from here? I could publish the list of 50 committers ids, here to this bugzilla, so they'd know if they have to speak up, or otherwise, they will be removed. Is that easiest approach? I sort of hate publishing a bunch of user IDs, but guess they are not secret and easily accessible by many other means. (And, as far as I know, there is no easy way to go from committer id to email, such as to notify them via email ... let me know if there is.) 

I guess we could literally just remove those that have not committed in the past year, and literally have them re-apply if needed ... but ... a) I could make errors in my change-log-to-group-membership comparisons, and b) in my experience, people wouldn't notice they no longer had access until 15 minutes before their deadline. 

To give a deadline, I'd like to say to have this resolved by 10/14 ... that is, have identified people to remove on 10/14 ... a few weeks after SR1 and Juno M2 ... so it would not be too stressful if someone was accidentally prematurely removed and had to get re-added before Juno M3 or Indigo SR2. 

Or ... this not a concern at all, and we should just skip it, let the group grow and grow? (I have been told I am a bit of a worrier :) 

Thanks for any suggestions. But in the absence of clear alternatives, I'll publish the list of unused access here, give a short while for people to speak up for exceptions or errors ... and then ask webmasters to remove inactives on 10/14.