RCBW: let's fix one Debian RC bug per-day

This page documents the RCBW initiative (for Release Critical Bugs of the Week) that I've started in September 2009.

The basic idea is very simple: since Debian accumulates a lot of RC bugs during its development cycle (and that is normal), we should all do our best to fix them during and near the freeze period. RCBW is meant to show that fixing RC bugs is:

• easy: in the sense that most of them (I'd say 60-70% IME) are packaging bugs, which every DD/DM should be able to tackle; by working on those you help the work of more experienced people which will have more time to work on the difficult/specific ones
• relatively quick: I haven't actually timed that, but I'd say that on average the actual work to fix a RC bug during a RCBW session takes about 20 minutes; all in all the time window is totally dominated by build time and chroot updates (which is idle time available for other tasks)
• sustainable in the long run: the above time figures enable to fix RC bugs day-by-day in spare time windows, even when you're in "low energy" mode
• terribly useful for the project: it gives a more realistic overview of how far Debian is, as a project, far from releasing a high quality operating system, helping the release team in making decisions
• fun, as you discover and learn many new packages, packaging techniques, packaging tools, programming languages, ...

On these topics I avoid stressing the very good explanations (and tricks) provided by Steve Langasek in his excellent RC bug squashing primer; you should really read it if you are interested in helping out with RC bugs.

Additionally, RCBW is meant to dispel the old Debian folklore that "NMUs are bad", quite the contrary: NMUs are good and helpful. In the old days of tight package control, we've grown accustomed to strong package ownership; according to that culture doing a NMU can be seen as a personal insult towards the current package maintainer. Nowadays things have changed: Debian is bigger, we routinely work in teams, and we have hard time spotting de facto MIA/inactive maintainers. Also we have delayed NMUs and appropriate guidelines that avoid the risk of impromptu uploads, when followed thoroughly.

As a personal experience on that: after 17 weeks of RCBW (at the time of writing) I haven't received a single complaint by NMU-ed maintainers, and I've received several "thank you" emails. The "worst" that has happened is that a couple of times NMU-ed maintainers have overridden my NMUs by uploading directly to unstable newer version of the involved packages. That's good anyhow, because in the end the bugs got fixed! and most likely that happened earlier than if the NMUs have not been attempted. Others people that have thus far participated in the RCBW "game" have enjoyed similar experiences.

Work-flow

To achieve that without burning yourself, I believe you should put into use a suitable NMU work-flow, here is mine, which is open for discussions and improvement suggestions (it is a version of those announced in my first post, improved over time):

1. go to UDD's bugs search and filter according to your own criteria (mine are embodied by either the bug squasher view or the sponsor view, depending on the mood)
2. choose an inspiring bug form the list which is at least 2 week old, study its log; 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 (this is most useful for FTBFS bugs, for others you can usually check for reproducibility installing from the archive)
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. lintian -F package_1.2-3.1.changes , if something shows up you must fix it, otherwise your upload will be refused at the end of the delay period
9. interdiff -z package_1.2-3.diff.gz package_1.2-3.1.diff.gz , check that no unexpected changes have slipped in
10. debsign package_1.2-3.1*changes , dput -e 2 package_1.2-3.1*changes (as allowed by devref §5.11.1)
11. nmudiff --delay 2 , in the text: briefly describe in what the patch consists, and mention explicitly devref §5.11.1

Blog posts

As RCBW is not only a technical exercise in making Debian RC-bug-free, but also in improving its internal culture about NMUs (YMMV, of course), letting others know that you are fixing RC bugs in packages other than yours if an important ingredient of the whole process. That's why I weekly blog about my squashes. Note that here vanity has a little role (well, OK, it always has some role, but here it is secondary), the goal is trying to motivate others in doing the same as you.

Again, as a personal experience I'm happy to report that several of the people which have joined RCBW over time have told me that my posts motivated them to fix RC bugs. That alone would be enough of a motivation/reword for doing and having done RCBW.

Below you can hence find a list of the most recent blog posts documenting my RCBW efforts; a full archive listing all of them is available on a separate page.

Kudos

• Steinar H. Gunderson which a few Debian releases ago started fixing one RC bug per day and (micro)blogging about that. RCBW has been shamelessly copied from his efforts.
• Gerfried Fuchs for an effort very similar to RCBW, whereas specifically targeted at bugs affecting stable releases (e.g.: the below 1000 milestone)
• Gregor Herrmann, which has been thus far one of the most enthusiastic followers of RCBW, and is still fixing steadily RC bugs, months after months (e.g. last posted entry, at the time of writing)
• Tim Retout, yet another enthusiastic follower of RCBW (e.g. NMUs, sponsored by UK weather)
• Evgeni Golov, who joined the RCBW fun too.
• Alexander Reichle-Schmehl for his sustained RC bug squashing activity
• Ben Hutchings for sustained RC bug squashing activities, during various release cycles, e.g. recent example
• Jonathan Wiltshire, for RCBW fun (e.g. week two)

... the long term plan is to list here all RCBW participants, but I'm lazy so this is opt-in: let me know your steady RC bug fixing efforts and I'll be happy to list you here. And remember: the point is just critical mass, the more we are, the higher the likelihood to attract more "players" in the useful RCBW game.