[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Attempted summary and thoughts (was Re: On maintainers not responding to bugs)

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

And perhaps most crucially:
(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 

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
(6b) Mr. X complains that the NMU broke his package, or that the patch was bad, 
or whatever.
(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  <neroden@fastmail.fm>

Read it and weep.

Reply to: