a question for all the candidates, but particularly Anthony Towns
The subject says "particularly Anthony Towns", because he has
expressed a desire for a greater and more active enforcement of such
things as the mailing list policy, and this seems another similar
area. But I would much like to hear from all the DPL candidates on
the following question.
We have an existing procedure for dealing with MIA maintainers, which
involves careful looks at their list activity and condition of the
packages. After an opportunity for discussion and further repeated
efforts at contact, the QA team decides the person is really MIA, and
orphans the maintainer's packages, making them available for others to
take and maintain. This process has shown itself workable and not
raised any serious hackles. Among other things, it's easily
reversible; if a MIA maintainer wakes up, she can always request
maintenance back, or if the package hasn't been adopted, just take it
back herself.
However, we occasionally have an equivalent problem: a maintainer who
*is* active on lists or is maintaining some packages, but who has
essentially abandoned maintenance of one or more other packages. This
is just as bad as the completely MIA maintainer, as regards the
quality of the other packages. There are a number of cases in the
archive of packages which have been maintained only by NMU for a long
period of time, or maintainers who have not responded to email
regarding particular packages even while they have been active in
other areas of Debian work.
One such case has been blocking an important gnucash bugfix for many
months, and I posted an uncontested announcement that I would be
taking over the blocking package as soon as a sarge freeze date is
announced, so that the important bug in question can get fixed in
sarge. But that's an ad-hoc procedure, and only seemed warranted to
me because it was blocking an important bug in my own package and
because tho blocking package is a library used only by my package and
one other. If these conditions had not obtained, I would not have
thought it appropriate to roll my own ad-hoc process this way.
The Developer's Reference Manual, in section 5.9.4 says you "need" to
orphan a package "if you can no longer maintain" it. (It does not
merely say that you should do so, or that you might want to.) Do we
need a procedure to deal with cases like this? Should the QA team
simply go ahead and devise one, as it did with the MIA problem?
Thomas
Reply to: