Re: Debian MIA check
First off, great work! Now I can remove the retirement item off my
old "todo" list. [1]
On Tue, 13 May 2003, James Troup wrote:
> On the 12th March I sent out a maintainer ping to 191 possibly
> inactive Debian developers. The list of developers was generated by
> looking first at all maintainers who didn't have a source package
> signed by (one of) their key(s) in unstable and then excluding from
> that anyone who had been seen (with a signed message) by echelon in
> the last 6 months.
>
"echelon" in this context meaning the mailing lists? As described in
http://lists.debian.org/debian-project/2000/debian-project-200001/msg00007.html
?
A second ping to unresponsive and bounces might be nice in case of mailer
problems. If a second ping is done it should probably be done before
changing account status. It should probably say the results of the last
ping and what will happen to their account.
> So to actually do anything about these MIA folks, some decisions had
> to be made about what to do with them WRT LDAP, their accounts etc.
>
> There will be 4 states for any given account in LDAP:
>
> o [default]
> o Emeritus
> o Disabled
> o Memorial
>
> The 'emeritus' state is for people who voluntarily retire. Their
> accounts are locked and their keys are moved to a separate keyring.
> Their email will continue to work for 6 months[a]. They lose vote,
> upload and -private reading privileges.
>
What happens to email going to 'emeritus' status Debian accounts after 6
months? Bounce?
> The 'disabled' state is for people who don't respond to maintainer
> pings, their email bounces, or whatever - basically someone who's MIA.
> Things are the same as 'emeritus', except their email won't continue
> to work. After a year in this state the accounts will be purged[b] and
> will be available for reuse.
>
I would encourage the bounced e-mail to say they are MIA. I'd also like to
see a canonical location to store MIA names and information (I.e. a web
page). What happened to the qa MIA database? The code's at
http://cvs.debian.org/mia/?cvsroot=qa but I can't find anything online.
I dislike having their accounts being available for reuse. It could cause
confusion. I could give many examples of potential confusion.
> People in 'emeritus' or even 'disabled' can come back at anytime
> without going through new-maintainer; provided they can prove they
> control the key(s) associated with the account.
>
But not nicely if their account gets reused. This could cause even more
confusion.
> The 'memorial' is a special state used for accounts that are disabled
> but which we don't want reused to avoid confusion (at best), e.g. with
> developers who've passed away.
>
What happens to e-mail going to these accounts? memorial bounce messages
may be nice... I guess a bounce of any kind would be appropriate.
> So, the 34 people who's email bounced and 90 people who didn't reply
> will have their account set to the 'disabled' status. The 28 people
> who asked to be retired will be set to 'emeritus'. If you know how to
> reach any of the people listed in [1] and [2] below, please feel free
> to contact them and get them to reply to wat@debian.org.
>
Are does 'emeritus' status last for 6 months only? If not, other retired
developers may be considered for 'emeritus' status. If so, what does their
account status switch to? removed?
> Finally, this is only the start of what will hopefully be an ongoing
> process; further pings based on other criteria are planned and also
> the results of Martin's MIA work will be acted on.
>
Automation deciding when to send a ping, sending a ping message, informing
everyone of the results... would be great. Regular cleanups like this one
would be good too.
> [b] Any files associated with the account will be either removed or
> moved to some holding area.
>
Some guidelines to determine which or when account files are
archived/removed may prevent future squabbles.
Thanks for your efforts.
[1] My old "todo" list is at
http://lists.debian.org/debian-user/2002/debian-user-200207/msg04836.html
but I have newer lists on local systems with items removed, changed and
added.
Drew Daniels
Reply to: