peter green wrote... > Nearly 3 months ago there was a mass bug filing on packages with dead > alioth lists as maintainer. Many of these bugs are still open with no > maintainer response
Yeah, but also a lot of people have already reacted. I got a lot of
e-mails sent to -close lately ...
> (note: it appears that the submitter of the bugs tried to usertag them
> but failed to actually do so)
Possibly. The tags were included in the announcement, nobody bothered to
comment.
> What should be done about these in the event that the maintainers
> don't sort it out? is it reasonable to make a NMU promoting the first
> co-maintainer to maintainer? is it reasonable to make a NMU orphaning
> the package? (and if-so should the list of co-maintainers be left in
> place?) In either case should a final warning be sent to the package's
> co-maintainers?
Orphaning the packages is quite harsh when it seems at least some
uploaders are still active - although not necessarily on that particular
package, so they certainly should see a gentle warning beforehand. The
bottom line still is: Maintainers should be encouraged to do their
chores, not be hushed away.
Also, orphaning is rather the last resort, the list of packages in that
state is already way too huge.
Looking at the current state I'm quite undecided. It's hard to tell why
some maintainers don't react. The first package I checked even had an
upload recently, ignoring the RC bug. They don't know? They don't care?
At the same time I'm not sure how much effort should be spent to enforce
a rule (the Debian policy thingie on address in Maintainer:) - a rule
that I consider important, that's why I did this MBF - while many
people appear to have a more relaxed view on this.
For the time being I'm thinking about technical means (yes, although
they don't solve social problems): It seems these bugs do not block
testing transition, that could be changed. And ftp-master could
autoreject packages with a defunct alioth address, the list is public.
Still, all this is an issue, and it should be resolved at freeze time.
Christoph
signature.asc
Description: PGP signature
