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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
