Monthly Archives: January 2011

Triage X Bugs of 2011 first Weeks (TXBW9-10-11)

I’ve been lasy about the reporting lately, so this is a 3 weeks update at once !

The bug count according to udd is down to 818. I guess this is due to Kibi‘s triaging on input related bugs, but I helped to close a few one too !

I kept my week numbering as before, so now I know the first bugs I pinged are more that 11 weeks old. I guess if some submitter did not answer in that delay, they will probably never do it. I think the bug count will go down again ! 😉

  • #451708 ping & close – xserver-xorg-input-synaptics: Option “GuestMouseOff” “true” not working.
  • #424743 ping & forwarded – X11 pen driver doesn’t work on tabletPC Fujitsu Stylistic 2300 (fix included).
  • #499664 ping, try nouveau – X fails to start with xserver-xorg-video-nv 1:2.1.12-1.
  • #512614 confirmed & upstream – xset dpms rejects reasonable values as illegal.
  • #512711 ping and later closed – All keypresses repeated roughly three times each, makes login impossible.
  • #513128 ping – X server crashes every time when gnome-screensaver starts.
  • #486356 merge with #482592 – numlock led is inversed (using numlockx) .
  • #515737 ping & closed – After upgrading from Etch to Lenny, mouse pointer is very slow and keys don’t repeat.
  • #515840 ping – Desktop is not using full screen after upgrade from etch to lenny.
  • #516860 closed after looking at the git history – Xorg with ‘-sharevts’ use almost 100% of the CPU.
  • #362434 ping & closed, suggested to try nouveau – nv has problems with xcursor-themes.
  • #502131 ping & closed – System gets into a `state’ and fails to process modifier keys.
  • #453296 closed (old ping unanswered) – MacBook: cannot assign right mouse click to lower Enter key.
  • #504537 ping – X server eats CPU on sparc.
  • #502313 ping – Applications are getting “ghost” Alt keypress events, but I press no keys.
  • #527118 ping – autoadded input devices kill X server.
  • #270887 forwarded – startx and xinit do not preserve client arguments.
  • #542542 closed after looking at the git history – non-VGA compatible graphics devices won’t run X.
  • #492888 ping – xorg ignores keystrokes.
  • #543210 merge with #492783 – Alt-F7 to return to X, passes F7 key to top focus’d window.
  • #524413 closed – xauth fails with xorg 7.4, this was actually an xinit bug and the git log lead to #549377 being closed…

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triaging bugs is not that hard !

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 control@b.d.o !

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!

  1. List bug from UDD: XSF unstable bugs sorted by date.
  2. 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).
  3. 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.
  4. 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).
  5. Decide what to do, most of the time, I will ‘ping’ the submitter.
  6. I’m a mutt user, and to my help the bts command 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 $n where $n is 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).
  7. In the message, always try to be kind and helpful, most of the time ask to test newer versions.
  8. Keep track of the pinged bugs, well I do it for my blog but it will be useful anyway, see below.
  9. When the submitter answers, just react accordingly, if the bug can be closed, then close it ! 😉
  10. 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.

Conclusion

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 !