I've been reading the discussion and trying to thresh something out of it. Four points and one proposal.
Point 1. ------- Contrary to some assumptions, answering "I got your bug report but I can't deal with it right now" is *very* useful, particularly in encouraging people to help. I've reported some bugs where I got prompt replies of "I can't reproduce it", or "I can reproduce it but I don't know how to fix it", or "I threw it upstream and we hope they'll fix it in the next century, but don't hold your breath", or even "Upstream is dead and I can't be bothered to fix it myself but feel free to send a patch", and I've been fairly happy. I've reported some similar bugs where I got no response, even after six months or more, and I was *not* happy. Communication is of value in and of itself. Major comments on the subject are at http://lists.debian.org/debian-devel/2007/02/msg00702.html and http://lists.debian.org/debian-devel/2007/02/msg00707.html and even http://lists.debian.org/debian-devel/2007/02/msg00736.html And perhaps most crucially: http://lists.debian.org/debian-devel/2007/02/msg00697.html (with followup http://lists.debian.org/debian-devel/2007/02/msg00771.html) The take-home message: --- Letting the submitter know that the bug has been looked at is valuable. --- Point 2. ------- If you don't have time to read/respond to bug reports within six months, you need help and you should ask for it. If you are not reading your bug reports (again, within six months to a year; I'm not talking about real prompt response here) you are not maintaining your package properly. You have several options: * Orphan it, and make QA uploads when you have the time. * File an RFH saying "I want to keep this package but I need more comaintainers in order to manage it properly", and encourage NMUs. Point 3. ------- Lack of response to bugs is usually a symptom of a larger problem; if that problem is something other than "I need help", then it's a serious problem. We should try to come up with some way of pinpointing and addressing these situations. The worse scenario IMNSHO is not merely a lack of response to bugs, but that *combined with* a proprietorial attitude towards the package. Consider this as the problematic scenario: (1) Person A files bug against package maintained by Mr. X (2) Mr. X doesn't respond for months (3) Person B files patch for bug (4) Mr. X doesn't respond for months (5) Person C NMUs (6a) Mr. X doesn't respond for months -or- (6b) Mr. X complains that the NMU broke his package, or that the patch was bad, or whatever. -or- (6c) Mr. X uploads reverting the NMU In this scenario, Mr. X should not be the maintainer. Period. And it happens fairly often. Actually, after describing the worst-case scenario, I am going to make a new tentative proposal: ---- If a package has a bug with a *patch* attached, where the *patch* has not been reviewed on by the maintainer(s) within six months, the package will be orphaned immediately; the maintainer will not be allowed to adopt it for at least a year, though he may comaintain and make uploads. (This should give a more accurate reflection of the real state of the package and make other people feel more free to fix the package.) ---- The number of *patched* bugs is a lot smaller than the number of bugs total. It is also *far* more frustrating to have a patched bug ignored than to have an unpatched bug ignored. Also, analyzing them is far more likely to give quick package improvements than analyzing other bugs. I have to mention ifupdown in this context. The ifupdown maintainer isn't asking for help (and was offended at the suggestion that he should). He isn't fixing bugs. He has 19 bugs marked "patch", most with no comment suggesting that there is any problem with the patch. And he has many bugs over a year old. And ifupdown does *not* get hundreds of bugs per month; there are fewer than 200 total. (No criticism of the hardworking comaintainer though, who's done excellent excellent work.) If the maintainer would release his death grip on the package and orphan it, I believe a team would spring up to maintain it almost immediately; I would be part of that team, and I expect the several previous NMUers might be too. A maintainer who deals with all his or her bugs can afford to be proprietorial. One who doesn't cannot afford to, but they so often do anyway. Point 3. -------- Tedious bug triage is a major portion of package maintenance. Some people wish it wasn't, but it is. When you volunteer to maintain a package, you're volunteering to do at least some, and probably a lot, of this. People should be given assistance and encouragement in doing it. I actually like doing it, but I have unfortunately relatively little time (sick family members). -- Nathanael Nerode <[EMAIL PROTECTED]> Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
