8 RC bugs in 8 days

I got back from vacation about 10 days ago. For the first time in recent years, I've spent 2 weeks of vacation mostly without email (excluding 2 "breaks" of 10 minutes each in an internet point, just to verify that my electronic world was not collapsing). The net result is that I feel very recharged and more productive both at work and for other tasks. Including Debian.

Hence, during last week, I've tried an experiment. When during the day I feel bored about a given task, instead of reloading compulsively the page of an online newspaper, instead of checking (once more) my email, instead of checking (once more) my feeds, I try to fix an RC bug.

For the first week, the result has been encouraging: one RC bug fixed per day (on the average, some day I haven't fixed any, some other 2 or 3):

• 30/08/2009 Debian bug #543067 - mergelog - tell autoreconf to install missing files (i.e., pass "-i")
• 31/08/2009 Debian bug #536971 - mergeant - add missing build-dep, thanks kibi for the triage
• 01/09/2009 Debian bug #521937 - gplanarity - add missing build-dep, thanks peter green for the triage
• 02/09/2009 Debian bug #537010 - gspot - add missing build-dep and CFLAGS/LIBS on libgnomeui
• 03/09/2009 Debian bug #536955 - gnubiff - patch configure.ac to add libgnomeui CFLAGS/LIBS
• 04/09/2009 Debian bug #536934 - xnee - patch configure.in to add libgnomeui CFLAGS/LIBS
• 05/09/2009 Debian bug #537033 - hspell-gui - patch configure.in to add libgnomeui CFLAGS/LIBS
• 06/09/2009 Debian bug #537030 - gnome-photo-printer - add missing build-dep on libglade2-dev

In some sense, this try to be kudos to the amazing initiative of Sesse, a few releases ago (or was it Lenny? my memory still sucks, no matter how recharged I feel). He has been fixing one RC bug a day for several months. I'm quite sure I won't be able to deliver the same result, but maybe this post will motivate other people, so that collectively we can fix a handful of RC bugs per day.

Of course in the beginning it's easy, because there are a lot of "simple" bugs to fix and also because (as you can notice in the list above) "clusters" of similar RC bugs, that require similar fixes, can be identified. But the effort is useful nevertheless, since it cleans up RC bug list enabling more capable people to fix more resistent bugs.

I'm gonna tag RC reports like this one with "rc" and "debian". If people follow up with similar initiatives we can rinse out of planet a feed of pretty good news for the Debian development community

In the interest of sharing best practices, here is my RC bug squashing workflow:

1. go to http://bts.turmzimmer.net/details.php, choose "both" (i.e. squeeze + sid) as distribution and sort by "bugnr" (so that you can avoid most recent reports, which are not yet NMU material)
2. choose an inspiring bug form the list which is at least 1 week old (better at least 2 or 3), study its log; for the moment, I tend to prefer neglected bug logs, where the maintainer has been unresponsive
3. apt-get source package , sudo cowbuilder --build package_1.2-3.dsc , install the result and check for bug reproducibility
4. fix the bug ! (yes, this is the easy step ), taking care of not changing anything else
5. dch --nmu
6. dpkg-source -b package-1.2/ , sudo cowbuilder --build package_1.2-3.1.dsc , check if the bug is fixed and the package otherwise working
7. lintian package_1.2-3.1.changes , check that there are no regressions in lintian errors wrt latest uploaded version
8. interdiff -z package_1.2-3.diff.gz package_1.2-3.1.diff.gz , check that no unexpected changes have slipped in
9. debsign package_1.2-3.1*changes , dput -e 2 package_1.2-3.1*changes (as allowed by devref §5.11.1)
10. nmudiff --delay 2 , in the text: briefly describe in what the patch consists, and mention devref §5.11.1

I welcome suggestions on how to improve the above workflow in order to be both more effective and more polite with maintainers (FWIW, all the maintainer feedback I've received thus far for the above NMUs has been totally positive: you rock guys.).