There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer’s job. While it’s true in general, some understaffed teams are so flooded by bugs that they just can’t do it.
I’ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks!
Then the thread evolved in lots of directions, I’m not following all of it, but there was the question of the bug triaging and as I’m doing it for the X packages, I want to share about my experience here.
The available triaging docs
The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project’s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don’t hesitate to reopen the BTS documentation whenever you need to write to firstname.lastname@example.org !
Now if all those docs don’t help you, then try to improve the docs as a first step ! 😉
Talk with the maintainer(s)
Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway.
My current process
This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!
- List bug from UDD: XSF unstable bugs sorted by date.
- Pick an old bug (once you answer and UDD runs, the bug moves down the list, so there are always old bugs on the top).
- Read the report, don’t be afraid by the subject, it might be unrelated, the bug might be merged with other bugs, then reading the other bugs can help.
- If relevant try to reproduce it. (most bugs in X are hardware related or specific to one setup, so it’s not that often that I have something to test).
- Decide what to do, most of the time, I will ‘ping’ the submitter.
- I’m a mutt user, and to my help the
btscommand as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.
So I launch
bts -m show $nwhere
$nis the bug number, and I can then answer the bug from mutt.
The triaging procedure suggest to ping -submitter, but using mutt it’s easier to just reply and add a -quiet to the bug number (this avoid spamming the debian-x with all my pings).
- In the message, always try to be kind and helpful, most of the time ask to test newer versions.
- Keep track of the pinged bugs, well I do it for my blog but it will be useful anyway, see below.
- When the submitter answers, just react accordingly, if the bug can be closed, then close it ! 😉
- If after some time, the bug are still not answered, consider closing them (I haven’t started that yet, but this will probably get the bug number down faster:) ).
Note: Sometime I don’t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. 😉
To submitters, please keep the bug CCed when you answer, thanks.
For the skeptics
Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don’t close bugs if I’m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! 😉
Also this work might look boring, but it’s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I’ve learned on Xorg.
As long as I have time for it, I’ll continue to triage bugs and I’d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! 😉
Get involved !