| 1 |
MIA database
|
| 2 |
============
|
| 3 |
|
| 4 |
This collection of small python scripts should allow you to keep track of
|
| 5 |
maintainers who are Missing In Action (MIA).
|
| 6 |
|
| 7 |
|
| 8 |
Querying information
|
| 9 |
--------------------
|
| 10 |
|
| 11 |
mia-history shows the history (i.e. all entries / contacts) of some or all
|
| 12 |
maintainers. It takes a regular expression as argument to which it tries
|
| 13 |
to match the UID. If you do not supply an argument, all maintainers in the
|
| 14 |
database will be shown.
|
| 15 |
|
| 16 |
mia-history has some options as well. Use --help to see them.
|
| 17 |
|
| 18 |
|
| 19 |
Adding Information
|
| 20 |
------------------
|
| 21 |
|
| 22 |
You can add information by sending e-mail to mia-<login>@qa.debian.org.
|
| 23 |
Every e-mail added to the database needs a summary. If your e-mail has
|
| 24 |
an X-MIA-Summary header, then the header will be used for the summary.
|
| 25 |
Otherwise, an e-mail is sent to mia@qa.debian.org asking for a summary.
|
| 26 |
|
| 27 |
For the summary you can use certain tags. There are tags which put
|
| 28 |
something into storage and other tags which take it out again. This means
|
| 29 |
that you can add a package and when the maintainer has fixed it, it can be
|
| 30 |
taken out again.
|
| 31 |
|
| 32 |
For example:
|
| 33 |
|
| 34 |
S-V: package_name
|
| 35 |
Fixed: package_name
|
| 36 |
|
| 37 |
The first entry means that you have contacted the maintainer of the package
|
| 38 |
"package_name" because the package had a very old Standards-Version (S-V).
|
| 39 |
The second entry tells the system that the maintained fixed the problem.
|
| 40 |
|
| 41 |
The "Summaries" section in mia.conf defines all possible tags. There are
|
| 42 |
currently four classes: tags in "ignore" will simply be ignored. Those in
|
| 43 |
"in" add an item while those in "out" remove an item. Finally, the tags in
|
| 44 |
"latest" mark the maintainer as being dealt with if the tag appears as the
|
| 45 |
last entry.
|
| 46 |
|
| 47 |
|
| 48 |
Who to add to the MIA DB?
|
| 49 |
-------------------------
|
| 50 |
|
| 51 |
There is currently no specific tool to find MIA maintainers and I am not
|
| 52 |
sure I even want to automate this task. One good way to find MIA people
|
| 53 |
is to look through changelogs or to look for NMUs; see the next section on
|
| 54 |
finding inactive maintainers.
|
| 55 |
|
| 56 |
You should only add someone to the MIA DB if it is quite clear that he is
|
| 57 |
MIA. Many people disappear only for a short time and then come back again.
|
| 58 |
They do not have to be added here. Also, some developers are very active
|
| 59 |
for Debian doing various things but neglecting their packages. They should
|
| 60 |
not be added either.
|
| 61 |
|
| 62 |
|
| 63 |
Finding inactive maintainers
|
| 64 |
----------------------------
|
| 65 |
|
| 66 |
There are various sources of information which can be used to track down
|
| 67 |
inactive maintainers. The echelon information in LDAP is very helpful, as
|
| 68 |
is subscribing to debian-devel-changes and looking for NMUs. However, note
|
| 69 |
that an NMU doesn't necessarily imply that a particular maintainer is
|
| 70 |
inactive. There must be a series of NMUs over some time period, otherwise
|
| 71 |
you cannot say someone is really inactive. Looking at the changelogs of
|
| 72 |
all the packages of a maintainers gives a pretty good picture of the
|
| 73 |
activity of the maintainer. Many NMUs happen when a FTBFS bug is filed and
|
| 74 |
the maintainer doesn't upload a fix in a reasonable time. Hence, it makes
|
| 75 |
sense to look for bugs which are tagged "fixed" and which are submitted by
|
| 76 |
buildd maintainers. One buildd maintainer's address is james@nocrew.org, so
|
| 77 |
you can see all the bugs he filed and which are "fixed now when you go to
|
| 78 |
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=submitter&data=james@nocrew.org&archive=no&include=fixed
|
| 79 |
|
| 80 |
|
| 81 |
Sponsored people who are inactive
|
| 82 |
---------------------------------
|
| 83 |
|
| 84 |
A major problem are sponsored people who are inactive. They are even
|
| 85 |
harder to pin down than inactive developers since no echelon information
|
| 86 |
is available about them, their contact details are not available on
|
| 87 |
db.debian.org, etc. One strategy which might be useful to find out about
|
| 88 |
their current status is to contact the developer who has actually uploaded
|
| 89 |
the package. After all, they are responsible for the upload and should
|
| 90 |
know what happened to the person they sponsored. Furthermore, one can
|
| 91 |
check http://nm.debian.org and see the status of the person in the NM
|
| 92 |
process. The site also lists the Application Manager of the applicant and
|
| 93 |
he might have more information.
|
| 94 |
|
| 95 |
One problem is that there is no list of sponsored people. Colin Watson
|
| 96 |
used the following scripts as a starting point to find sponsored people:
|
| 97 |
|
| 98 |
grep-available -rFMaintainer -nsMaintainer . > maintainers
|
| 99 |
|
| 100 |
(gpg --no-default-keyring --keyring ./debian-keyring.gpg --list-keys; \
|
| 101 |
gpg --no-default-keyring --keyring ./debian-keyring.pgp --list-keys) \
|
| 102 |
| grep -v '^\[.*\]$' | grep . | sort -u > keyring-maintainers
|
| 103 |
|
| 104 |
perl -e 'open K, "keyring-maintainers";
|
| 105 |
while (<K>) { $k{lc $_} = 1; }
|
| 106 |
close K;
|
| 107 |
open M, "maintainers";
|
| 108 |
while (<M>) { print unless $k{lc $_}; }
|
| 109 |
close M;' > sponsored-maintainers
|
| 110 |
|
| 111 |
However, this is only an approximation. It's still necessary to go through
|
| 112 |
the file by hand and remove the ones who use different e-mail addresses from
|
| 113 |
the ones in their GPG keys. Thus, most of the work is weeding through the
|
| 114 |
sponsored-maintainers file and comparing it more intelligently to
|
| 115 |
keyring-maintainers. Once a current listing of sponsored people has been
|
| 116 |
made with this method, one can start checking the status of all sponsored
|
| 117 |
people against http://nm.debian.org/ and see who's left, or which applicants
|
| 118 |
who are "on hold" in the NM process have packages in the archive.
|
| 119 |
|
| 120 |
|
| 121 |
Checking who to contact
|
| 122 |
-----------------------
|
| 123 |
|
| 124 |
After about 3 weeks, you should contact the maintainer again if he didn't
|
| 125 |
fix the package in the meantime. mia-check shows all maintainers which you
|
| 126 |
should contact again.
|
| 127 |
|
| 128 |
Furthermore, mia-check has a --templates option which creates e-mail
|
| 129 |
templates you can load into mutt. Please remove the "Just for reference,
|
| 130 |
the history is:", however -- it is only meant for you when you write the
|
| 131 |
e-mail.
|
| 132 |
|
| 133 |
|
| 134 |
Orphaning a package
|
| 135 |
-------------------
|
| 136 |
|
| 137 |
If a maintainer has been contacted several times and the package has still
|
| 138 |
not been fixed, it is time to orphan the package. The script wnpp-orphan
|
| 139 |
can be used to generate a template to file a proper WNPP bug. It will
|
| 140 |
generate a nice message and include some information about the package.
|
| 141 |
wnpp-orphan takes one or more packages as its arguments. Furthermore, you
|
| 142 |
can specify an action with -a. The action determines which template is
|
| 143 |
used to generate the WNPP bug report. The default action is "mia". It
|
| 144 |
asks for a justification why the package is being orphaned (this can be
|
| 145 |
left blank, though) and then generates a template which will CC the
|
| 146 |
maintainer and also Bcc the MIA database. This action is the most useful
|
| 147 |
for doing MIA work. However, the other actions might come in handy too.
|
| 148 |
They are:
|
| 149 |
|
| 150 |
- qa: file a proper WNPP bug for a package that has been orphaned by
|
| 151 |
the maintainer and is now owned by QA. This action is useful in
|
| 152 |
combination with wnpp-publicize (in /org/qa.debian.org/data/wnpp).
|
| 153 |
- orphan: to orphan a package
|
| 154 |
- rfa: to put a package up for adoption
|
| 155 |
|
| 156 |
|
| 157 |
Some final thoughts
|
| 158 |
-------------------
|
| 159 |
|
| 160 |
What do we expect from maintainers? Do we want volunteers who are there
|
| 161 |
all the time or do we accept that volunteers are busy with other stuff
|
| 162 |
sometime? Is an NMU a normal and accepted thing (as it used to be a couple
|
| 163 |
of years ago) or is it a bad thing to get an NMU (as it is nowadays)?
|
| 164 |
Should one person maintain a package or is it ok if other people help out
|
| 165 |
sometimes?
|
| 166 |
|
| 167 |
The MIA effort should increase the quality in Debian, but it must not
|
| 168 |
become a witch hunt.
|
| 169 |
|
| 170 |
|
| 171 |
Getting new additions automatically
|
| 172 |
-----------------------------------
|
| 173 |
|
| 174 |
All new additions made to the MIA DB are sent to the mia@qa.debian.org
|
| 175 |
alias. If you want to be involved with finding MIA maintainers, ask
|
| 176 |
admin@qa.debian.org to subscribe you.
|
| 177 |
|
| 178 |
|
| 179 |
Feedback
|
| 180 |
--------
|
| 181 |
|
| 182 |
If you have any questions or good ideas, please email mia@qa.debian.org
|
| 183 |
|
Parent Directory
| 
Revision Log