Contents of /trunk/mia/README

MIA database
============

This collection of small python scripts should allow you to keep track of
maintainers who are Missing In Action (MIA).


Querying information
--------------------

mia-history shows the history (i.e. all entries / contacts) of some or all
maintainers.  It takes a regular expression as argument to which it tries
to match the UID.  If you do not supply an argument, all maintainers in the
database will be shown.

mia-history has some options as well.  Use --help to see them.


Adding Information
------------------

You can add information by sending e-mail to mia-<login>@qa.debian.org.
Every e-mail added to the database needs a summary.  If your e-mail has
an X-MIA-Summary header, then the header will be used for the summary.
Otherwise, an e-mail is sent to mia@qa.debian.org asking for a summary.

For the summary you can use certain tags.  There are tags which put
something into storage and other tags which take it out again.  This means
that you can add a package and when the maintainer has fixed it, it can be
taken out again.

For example:

  S-V: package_name
  Fixed: package_name

The first entry means that you have contacted the maintainer of the package
"package_name" because the package had a very old Standards-Version (S-V).
The second entry tells the system that the maintained fixed the problem.

The "Summaries" section in mia.conf defines all possible tags.  There are
currently four classes: tags in "ignore" will simply be ignored.  Those in
"in" add an item while those in "out" remove an item.  Finally, the tags in
"latest" mark the maintainer as being dealt with if the tag appears as the
last entry.


Who to add to the MIA DB?
-------------------------

There is currently no specific tool to find MIA maintainers and I am not
sure I even want to automate this task.  One good way to find MIA people
is to look through changelogs or to look for NMUs; see the next section on
finding inactive maintainers.

You should only add someone to the MIA DB if it is quite clear that he is
MIA.  Many people disappear only for a short time and then come back again.
They do not have to be added here.  Also, some developers are very active
for Debian doing various things but neglecting their packages.  They should
not be added either.


Finding inactive maintainers
----------------------------

There are various sources of information which can be used to track down
inactive maintainers.  The echelon information in LDAP is very helpful, as
is subscribing to debian-devel-changes and looking for NMUs.  However, note
that an NMU doesn't necessarily imply that a particular maintainer is
inactive.  There must be a series of NMUs over some time period, otherwise
you cannot say someone is really inactive.  Looking at the changelogs of
all the packages of a maintainers gives a pretty good picture of the
activity of the maintainer.  Many NMUs happen when a FTBFS bug is filed and
the maintainer doesn't upload a fix in a reasonable time.  Hence, it makes
sense to look for bugs which are tagged "fixed" and which are submitted by
buildd maintainers.  One buildd maintainer's address is james@nocrew.org, so
you can see all the bugs he filed and which are "fixed now when you go to
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=submitter&data=james@nocrew.org&archive=no&include=fixed


Sponsored people who are inactive
---------------------------------

A major problem are sponsored people who are inactive.  They are even
harder to pin down than inactive developers since no echelon information
is available about them, their contact details are not available on
db.debian.org, etc.  One strategy which might be useful to find out about
their current status is to contact the developer who has actually uploaded
the package.  After all, they are responsible for the upload and should
know what happened to the person they sponsored.  Furthermore, one can
check http://nm.debian.org and see the status of the person in the NM
process.  The site also lists the Application Manager of the applicant and
he might have more information.

One problem is that there is no list of sponsored people.  Colin Watson
used the following scripts as a starting point to find sponsored people:

  grep-available -rFMaintainer -nsMaintainer . > maintainers

  (gpg --no-default-keyring --keyring ./debian-keyring.gpg --list-keys; \
   gpg --no-default-keyring --keyring ./debian-keyring.pgp --list-keys) \
    | grep -v '^\[.*\]$' | grep . | sort -u > keyring-maintainers

  perl -e 'open K, "keyring-maintainers";
           while (<K>) { $k{lc $_} = 1; }
           close K;
           open M, "maintainers";
           while (<M>) { print unless $k{lc $_}; }
           close M;' > sponsored-maintainers

However, this is only an approximation.  It's still necessary to go through
the file by hand and remove the ones who use different e-mail addresses from
the ones in their GPG keys.  Thus, most of the work is weeding through the
sponsored-maintainers file and comparing it more intelligently to
keyring-maintainers.  Once a current listing of sponsored people has been
made with this method, one can start checking the status of all sponsored
people against http://nm.debian.org/ and see who's left, or which applicants
who are "on hold" in the NM process have packages in the archive.


Checking who to contact
-----------------------

After about 3 weeks, you should contact the maintainer again if he didn't
fix the package in the meantime.  mia-check shows all maintainers which you
should contact again.

Furthermore, mia-check has a --templates option which creates e-mail
templates you can load into mutt.  Please remove the "Just for reference,
the history is:", however -- it is only meant for you when you write the
e-mail.


Orphaning a package
-------------------

If a maintainer has been contacted several times and the package has still
not been fixed, it is time to orphan the package.  The script wnpp-orphan
can be used to generate a template to file a proper WNPP bug.  It will
generate a nice message and include some information about the package.
wnpp-orphan takes one or more packages as its arguments.  Furthermore, you
can specify an action with -a.  The action determines which template is
used to generate the WNPP bug report.  The default action is "mia".  It
asks for a justification why the package is being orphaned (this can be
left blank, though) and then generates a template which will CC the
maintainer and also Bcc the MIA database.  This action is the most useful
for doing MIA work.  However, the other actions might come in handy too.
They are:

  - qa: file a proper WNPP bug for a package that has been orphaned by
    the maintainer and is now owned by QA.  This action is useful in
    combination with wnpp-publicize (in /org/qa.debian.org/data/wnpp).
  - orphan: to orphan a package
  - rfa: to put a package up for adoption


Some final thoughts
-------------------

What do we expect from maintainers?  Do we want volunteers who are there
all the time or do we accept that volunteers are busy with other stuff
sometime?  Is an NMU a normal and accepted thing (as it used to be a couple
of years ago) or is it a bad thing to get an NMU (as it is nowadays)?
Should one person maintain a package or is it ok if other people help out
sometimes?

The MIA effort should increase the quality in Debian, but it must not
become a witch hunt.


Getting new additions automatically
-----------------------------------

All new additions made to the MIA DB are sent to the mia@qa.debian.org
alias.  If you want to be involved with finding MIA maintainers, ask
admin@qa.debian.org to subscribe you.


Feedback
--------

If you have any questions or good ideas, please email mia@qa.debian.org

1	tbm	217	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	tbm	302	You can add information by sending e-mail to mia-<login>@qa.debian.org.
23	tbm	217	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	tbm	677	S-V: package_name
35			Fixed: package_name
36	tbm	217
37	tbm	302	The first entry means that you have contacted the maintainer of the package
38	tbm	459	"package_name" because the package had a very old Standards-Version (S-V).
39	tbm	302	The second entry tells the system that the maintained fixed the problem.
40	tbm	217
41	tbm	677	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	tbm	217
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	tbm	641	is to look through changelogs or to look for NMUs; see the next section on
54			finding inactive maintainers.
55	tbm	217
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	tbm	641	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	tbm	508	Sponsored people who are inactive
82			---------------------------------
83
84	tbm	521	A major problem are sponsored people who are inactive. They are even
85	tbm	508	harder to pin down than inactive developers since no echelon information
86	tbm	521	is available about them, their contact details are not available on
87	tbm	508	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	tbm	521	used the following scripts as a starting point to find sponsored people:
97	tbm	508
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	tbm	519	while (<K>) { $k{lc $_} = 1; }
106	tbm	508	close K;
107			open M, "maintainers";
108	tbm	519	while (<M>) { print unless $k{lc $_}; }
109	tbm	508	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	tbm	217	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	tbm	458	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	tbm	461	asks for a justification why the package is being orphaned (this can be
145	tbm	507	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	tbm	461	They are:
149	tbm	458
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	tbm	217	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	tbm	509	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	tbm	217	Feedback
180			--------
181
182	tbm	940	If you have any questions or good ideas, please email mia@qa.debian.org
183	tbm	217
Name	Value
svn:eol-style	native
svn:keywords	Author Date Id Revision