| 1 |
MIA Tracking Database
|
| 2 |
=====================
|
| 3 |
|
| 4 |
This is a collection of python scripts to keep track of maintainers who are
|
| 5 |
Missing In Action (MIA). If you think a maintainer is MIA, read on.
|
| 6 |
|
| 7 |
|
| 8 |
Verifying MIAness
|
| 9 |
-----------------
|
| 10 |
|
| 11 |
First, you should check if the database already knows about the maintainer:
|
| 12 |
$ ./mia-query myon@debian.org
|
| 13 |
(Sorry, this tool is only available to developers.)
|
| 14 |
|
| 15 |
The DDPO pages are a nice overview to see NMUs and bug counts:
|
| 16 |
http://qa.debian.org/developer.php?login=myon@debian.org&ordering=1
|
| 17 |
Ordering by last upload date makes spotting the oldest packages easier.
|
| 18 |
|
| 19 |
You should them check the PTS for uploads, and the BTS for maintainer followups
|
| 20 |
on open bugs. (This is not automated yet, unfortunately.)
|
| 21 |
|
| 22 |
The echelon information from LDAP shows last the last activity on Debian lists
|
| 23 |
identified by "From:" headers and gpg signatures.
|
| 24 |
$ ldapsearch -u -x -H ldap://db.debian.org -b dc=debian,dc=org uid=myon |
|
| 25 |
grep -A2 activity
|
| 26 |
|
| 27 |
Usually, there should not have been any substantial activity for at least 3,
|
| 28 |
most often 6 months, before pestering the maintainer is warranted, because
|
| 29 |
people often drop out for shorter periods and come back themselves. Also, some
|
| 30 |
developers are very active for Debian doing various things but neglecting their
|
| 31 |
packages. They should not be added either, except if the packages look very
|
| 32 |
bad.
|
| 33 |
|
| 34 |
|
| 35 |
Notifying the MIA team
|
| 36 |
----------------------
|
| 37 |
|
| 38 |
The easiest way is to mail <mia@qa.debian.org>. The people reading this
|
| 39 |
address will then take care of further steps, i.e. they will put the message in
|
| 40 |
the database, investigate the situation, ping the maintainer, and depending on
|
| 41 |
the outcome, orphan the packages, or suggest other action to undertake.
|
| 42 |
|
| 43 |
Please note that due to the amount and diverse nature of messages sent to
|
| 44 |
<mia@qa.debian.org>, we usually do not acknowledge receiving your input. If
|
| 45 |
you want to have feedback, use the 'mia-query' tool, ask on #debian-qa on
|
| 46 |
irc.oftc.net, or state so in your message.
|
| 47 |
|
| 48 |
[Stop reading here if you just wanted to report a single maintainer.]
|
| 49 |
|
| 50 |
|
| 51 |
Adding information to the database
|
| 52 |
----------------------------------
|
| 53 |
|
| 54 |
You can add information directly to the database by sending e-mail to
|
| 55 |
mia-<id>@qa.debian.org. 'id' is either the LDAP login name, or the email
|
| 56 |
address with @ replaced by '='. (Please don't expose these addresses in the
|
| 57 |
BTS/on the web/etc., so using 'Bcc' is encouraged.)
|
| 58 |
|
| 59 |
Every e-mail added to the database needs a summary. If your e-mail has an
|
| 60 |
X-MIA-Summary header, then the header will be used for the summary. Otherwise,
|
| 61 |
an e-mail is sent to mia@qa.debian.org asking for a summary. The 'mia-bounce'
|
| 62 |
script is handy to bounce messages to the database (requires 'formail').
|
| 63 |
|
| 64 |
If unsure, send your message to mia@qa.debian.org instead and we will put the
|
| 65 |
message into the database for you.
|
| 66 |
|
| 67 |
|
| 68 |
Encoding in the database
|
| 69 |
------------------------
|
| 70 |
|
| 71 |
The MIA database consists of a mbox per maintainer in the db/ subdirectory.
|
| 72 |
The corresponding status is stored in .summary files alongside. Via the
|
| 73 |
X-MIA-Summary field and via a response to the mail if such mail was not
|
| 74 |
present, one can set one of the above status items. 'none' is not settable,
|
| 75 |
all the others are simply settable by mentioning them. You can set multiple such
|
| 76 |
entries by separating them with a comma, a semi-colon will terminate the
|
| 77 |
parseable section, you can add a short summary of the contents of the mail
|
| 78 |
after the ';'.
|
| 79 |
|
| 80 |
'mia-query' allows you to query the database. Run mia-query --help to get help
|
| 81 |
about the usage.
|
| 82 |
|
| 83 |
Short summary for the other tools;
|
| 84 |
* mia-todo: prints a todo list of maintainers where action is required.
|
| 85 |
Use --help to see the various levels to query information.
|
| 86 |
* mia-save: allows to append summary lines to the database that are not related
|
| 87 |
to incoming messages.
|
| 88 |
* mia-bounce: helper script to inject X-MIA-Summary headers and bounce messages
|
| 89 |
to the MIA database
|
| 90 |
* mia-record: the backend tool that processes messages sent to
|
| 91 |
mia-*@qa.debian.org.
|
| 92 |
|
| 93 |
|
| 94 |
Available summary tags
|
| 95 |
----------------------
|
| 96 |
|
| 97 |
There are two summary axes, status and prod level:
|
| 98 |
|
| 99 |
- Status: How badly MIA does this maintainer look/is this maintainer?
|
| 100 |
- none # not listed
|
| 101 |
|
| 102 |
The following are tags incremental, they don't decrease except after an 'ok',
|
| 103 |
which is a reset.
|
| 104 |
- ok # without parameter: reset status
|
| 105 |
- busy # Some activity, but looks time-starved
|
| 106 |
- inactive # no activity at all for a while (> 3m)
|
| 107 |
- unresponsive # no response from MIA pings, or response but no action
|
| 108 |
- retiring # maintainer noted intent to retire (or drop out of NM), but
|
| 109 |
did not follow up yet
|
| 110 |
- mia # No response even to last ping, all packages can be orphaned at
|
| 111 |
sight, wat can be sent
|
| 112 |
- retired # Has officially announced retirement (or termination of
|
| 113 |
packaging involvement for non-DDs)
|
| 114 |
- needs-wat # No packages anymore, but has Debian account ("where art thou")
|
| 115 |
- role # Is not a flesh and blood maintainer at all, but mailinglist or
|
| 116 |
other role address
|
| 117 |
|
| 118 |
The above base status tags can temporarily suspended by the following:
|
| 119 |
- ok for <time> # To override a non-ok severity temporarily, for example, if
|
| 120 |
the overall situation doesn't seem to warrant a(nother)
|
| 121 |
prod, this enables you to postpone. <time> is 2m3w2d" for
|
| 122 |
example, and means that the validity of 'ok' is valid for
|
| 123 |
2 months, 3 weeks and 2 days)
|
| 124 |
- npa [for <t>] # similar to 'ok', means 'non-packaging activity'. Also
|
| 125 |
protects against wat in case of no packages left. Examples
|
| 126 |
are buildd admins, porters, AMs. Defaults to 1y review.
|
| 127 |
- willfix [for <t>] # similar to 'ok', means promise of resuming/increasing
|
| 128 |
activity. Suspends more severe status until expiring
|
| 129 |
(default 4w)
|
| 130 |
If you want to preliminary terminate a too-long suspension, use '<suspend>
|
| 131 |
for 0d'.
|
| 132 |
|
| 133 |
- Prod-level:
|
| 134 |
- none # No pings been sent since last 'ok'
|
| 135 |
- nice # Asked nicely whether someone maybe is lacking sufficient time/interest
|
| 136 |
- prod # Noted some packages look bad, and asked what's up and whether
|
| 137 |
maybe some/all packages are better orphaned
|
| 138 |
- last-warning # Noted there is no improvement at all, warned that we'll proceed
|
| 139 |
orphaning
|
| 140 |
- wat # warning about account disabling has been sent
|
| 141 |
|
| 142 |
You can also indicate a mail from MIA to the maintainer, or a response from
|
| 143 |
the maintainer to MIA, by using 'out' and 'in' respectively. Use neither
|
| 144 |
'out' nor 'in' for all other mails (external hints, observed mails/activity
|
| 145 |
from maintainer).
|
| 146 |
|
| 147 |
Prod-levels also act like a suspend to allow the maintainer to reply,
|
| 148 |
similarly they take ' for 1w' as parameter (defaults to 3 weeks).
|
| 149 |
|
| 150 |
|
| 151 |
Mailing the maintainer
|
| 152 |
----------------------
|
| 153 |
|
| 154 |
First of all, be nice to people. We are pestering them, this is already rude
|
| 155 |
enough. Ask them how they are doing. Including a "thanks for your
|
| 156 |
contribution to Debian" is always a nice thing (even if they have been MIA for
|
| 157 |
years), etc...
|
| 158 |
|
| 159 |
It is tempting to have templates for the messages you send. However,
|
| 160 |
hand-writing the messages makes them much more personal. The reasons people
|
| 161 |
are MIA are so diverse that a template is usually only good for the very first
|
| 162 |
contact.
|
| 163 |
|
| 164 |
Finally, while answering to replies maintainers send is not always required, it
|
| 165 |
is a nice gesture. Don't send MIA-pings if you know you will away for some
|
| 166 |
days.
|
| 167 |
|
| 168 |
After 3 weeks, you should contact the maintainer again if they did not update
|
| 169 |
their packages in the meantime. The 'mia-todo' tool tells you which
|
| 170 |
maintainers need being contacted.
|
| 171 |
|
| 172 |
|
| 173 |
Orphaning a package
|
| 174 |
-------------------
|
| 175 |
|
| 176 |
If a maintainer has been contacted several times and the package has still
|
| 177 |
not been fixed, it is time to orphan the package. The script wnpp-orphan
|
| 178 |
can be used to generate a template to file a proper WNPP bug. It will
|
| 179 |
generate a nice message and include some information about the package.
|
| 180 |
wnpp-orphan takes one or more packages as its arguments. Furthermore, you
|
| 181 |
can specify an action with -a. The action determines which template is
|
| 182 |
used to generate the WNPP bug report. The default action is "mia". It
|
| 183 |
asks for a justification why the package is being orphaned (this can be
|
| 184 |
left blank, though) and then generates a template which will CC the
|
| 185 |
maintainer and also Bcc the MIA database. This action is the most useful
|
| 186 |
for doing MIA work. However, the other actions might come in handy too.
|
| 187 |
They are:
|
| 188 |
|
| 189 |
- qa: file a proper WNPP bug for a package that has been orphaned by
|
| 190 |
the maintainer and is now owned by QA. This action is useful in
|
| 191 |
combination with wnpp-publicize (in /org/qa.debian.org/data/wnpp).
|
| 192 |
- orphan: to orphan a package
|
| 193 |
- rfa: to put a package up for adoption
|
| 194 |
|
| 195 |
|
| 196 |
Finding inactive maintainers
|
| 197 |
----------------------------
|
| 198 |
|
| 199 |
There is currently no specific tool to find MIA maintainers and we are unsure
|
| 200 |
if even want to automate this task. One way to systematically find MIA
|
| 201 |
people is subscribing to debian-devel-changes and looking for NMUs. However,
|
| 202 |
note that an NMU doesn't necessarily imply that a particular maintainer is
|
| 203 |
inactive. There must be a series of NMUs over some time period, otherwise
|
| 204 |
you cannot say someone is really inactive. Looking at the changelogs of
|
| 205 |
all the packages of a maintainers gives a pretty good picture of the
|
| 206 |
activity of the maintainer. Many NMUs happen when a FTBFS bug is filed and
|
| 207 |
the maintainer doesn't upload a fix in a reasonable time. Hence, it makes
|
| 208 |
sense to look for bugs which are tagged "fixed" and which are submitted by
|
| 209 |
buildd maintainers. One buildd maintainer's address is james@nocrew.org, so
|
| 210 |
you can see all the bugs he filed and which are "fixed now when you go to
|
| 211 |
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=submitter&data=james@nocrew.org&archive=no&include=fixed
|
| 212 |
|
| 213 |
Other sources are lintian warnings, and mass bug filings like library
|
| 214 |
transitions or policy updates (like /usr/doc -> /usr/share/doc).
|
| 215 |
|
| 216 |
|
| 217 |
Sponsored people who are inactive
|
| 218 |
---------------------------------
|
| 219 |
|
| 220 |
A major problem are sponsored people who are inactive. They are even
|
| 221 |
harder to pin down than inactive developers since no echelon information
|
| 222 |
is available about them, their contact details are not available on
|
| 223 |
db.debian.org, etc. One strategy which might be useful to find out about
|
| 224 |
their current status is to contact the developer who has actually uploaded
|
| 225 |
the package. After all, they are responsible for the upload and should
|
| 226 |
know what happened to the person they sponsored. Furthermore, one can
|
| 227 |
check http://nm.debian.org and see the status of the person in the NM
|
| 228 |
process. The site also lists the Application Manager of the applicant and
|
| 229 |
they might have more information.
|
| 230 |
|
| 231 |
One problem is that there is no list of sponsored people. Colin Watson
|
| 232 |
used the following scripts as a starting point to find sponsored people:
|
| 233 |
|
| 234 |
grep-available -rFMaintainer -nsMaintainer . > maintainers
|
| 235 |
|
| 236 |
(gpg --no-default-keyring --keyring ./debian-keyring.gpg --list-keys; \
|
| 237 |
gpg --no-default-keyring --keyring ./debian-keyring.pgp --list-keys) \
|
| 238 |
| grep -v '^\[.*\]$' | grep . | sort -u > keyring-maintainers
|
| 239 |
|
| 240 |
perl -e 'open K, "keyring-maintainers";
|
| 241 |
while (<K>) { $k{lc $_} = 1; }
|
| 242 |
close K;
|
| 243 |
open M, "maintainers";
|
| 244 |
while (<M>) { print unless $k{lc $_}; }
|
| 245 |
close M;' > sponsored-maintainers
|
| 246 |
|
| 247 |
However, this is only an approximation. It's still necessary to go through
|
| 248 |
the file by hand and remove the ones who use different e-mail addresses from
|
| 249 |
the ones in their GPG keys. Thus, most of the work is weeding through the
|
| 250 |
sponsored-maintainers file and comparing it more intelligently to
|
| 251 |
keyring-maintainers. Once a current listing of sponsored people has been
|
| 252 |
made with this method, one can start checking the status of all sponsored
|
| 253 |
people against http://nm.debian.org/ and see who's left, or which applicants
|
| 254 |
who are "on hold" in the NM process have packages in the archive.
|
| 255 |
|
| 256 |
[Update: this section is outdated, carnivore improves the situation considerably]
|
| 257 |
|
| 258 |
|
| 259 |
Co-maintainers
|
| 260 |
--------------
|
| 261 |
|
| 262 |
Some people are only co-maintainers (Uploaders: in the control file) of
|
| 263 |
packages. Depending on how the maintenance team works, it can be hard to track
|
| 264 |
if a certain person has done any work. Additionally, there is currently no
|
| 265 |
standard procedure to request an inactive co-maintainer to be removed from the
|
| 266 |
uploaders list, resulting in many obsolete entries in the list of all
|
| 267 |
maintainers. Maintainers should be encouraged to drop co-maintainers from
|
| 268 |
their packages if they do not contribute. If you take over a package, please
|
| 269 |
remove the original maintainer unless they are going to contribute in the
|
| 270 |
future.
|
| 271 |
|
| 272 |
|
| 273 |
Some final thoughts
|
| 274 |
-------------------
|
| 275 |
|
| 276 |
What do we expect from maintainers? Do we want volunteers who are there
|
| 277 |
all the time or do we accept that volunteers are busy with other stuff
|
| 278 |
sometime? Is an NMU a normal and accepted thing (as it used to be a couple
|
| 279 |
of years ago) or is it a bad thing to get an NMU (as it is nowadays)?
|
| 280 |
Should one person maintain a package or is it ok if other people help out
|
| 281 |
sometimes?
|
| 282 |
|
| 283 |
The MIA effort should increase the quality in Debian, but it must not
|
| 284 |
become a witch hunt.
|
| 285 |
|
| 286 |
|
| 287 |
Getting involved
|
| 288 |
----------------
|
| 289 |
|
| 290 |
All new additions made to the MIA DB are sent to the mia@qa.debian.org
|
| 291 |
alias. If you want to be involved with finding MIA maintainers, ask
|
| 292 |
mia@qa.debian.org to subscribe you. You do not even have to be a Debian
|
| 293 |
Developer, there are ways to get you access to the data and tools you need.
|
| 294 |
|
| 295 |
If you have any questions or good ideas, please email mia@qa.debian.org.
|
| 296 |
|
| 297 |
-- Jeroen van Wolffelaar <jeroen@debian.org>
|
| 298 |
Christoph Berg <myon@debian.org> Thu, 30 Mar 2006 15:10:35 +0200
|
| 299 |
|
| 300 |
# vim: et
|
Parent Directory
| 
Revision Log