ca0278f2117ad8546e313d25d489df1fb43e2cd4
[homepage.git] / hacking / debian / rcbw.mdwn
1 # RCBW: let's fix one Debian RC bug per-day
2
3 This page documents the **RCBW initiative** (for **Release Critical Bugs of the
4 Week**) that [[I've started|blog/posts/2009/09/rc_bug_of_the_day_-_again]] in
5 September 2009.
6
7 The basic idea is very simple: since Debian accumulates a lot of
8 [RC bugs](http://bugs.debian.org/release-critical/) during its development
9 cycle (and that is normal), we should all do our best to fix them during *and
10 near* the freeze period. RCBW is meant to show that fixing RC bugs is:
11
12 - **easy**: in the sense that most of them (I'd say 60-70% IME) are packaging
13   bugs, which every DD/DM should be able to tackle; by working on those you
14   help the work of more experienced people which will have more time to work on
15   the difficult/specific ones
16 - relatively **quick**: I haven't actually timed that, but I'd say that on
17   average the actual work to fix a RC bug during a RCBW session takes about 20
18   minutes; all in all the time window is totally dominated by build time and
19   chroot updates (which is idle time available for other tasks)
20 - **sustainable** in the long run: the above time figures enable to fix RC bugs
21   day-by-day in spare time windows, even when you're in "low energy" mode
22 - **terribly useful** for the project: it gives a more realistic overview of
23   how far Debian is, as a project, far from releasing a high quality operating
24   system, helping the release team in making decisions
25 - **fun**, as you discover and learn many new packages, packaging techniques,
26   packaging tools, programming languages, ...
27
28 On these topics I avoid stressing the very good explanations (and tricks)
29 provided by Steve Langasek in his excellent
30 [RC bug squashing primer](http://people.debian.org/~vorlon/rc-bugsquashing.html);
31 you should really read it if you are interested in helping out with RC bugs.
32
33 Additionally, RCBW is meant to dispel the old Debian folklore that "NMUs are
34 bad", quite the contrary: **NMUs are good and helpful**. In the old days of
35 tight package control, we've grown accustomed to strong package ownership;
36 according to that culture doing a NMU can be seen as a personal insult towards
37 the current package maintainer. Nowadays things have changed: Debian is bigger,
38 we routinely work in teams, and we have hard time spotting de facto
39 MIA/inactive maintainers. Also we have
40 [**delayed NMUs and appropriate guidelines**](http://www.debian.org/doc/developers-reference/pkgs.html#nmu-guidelines)
41 that avoid the risk of impromptu uploads, when followed thoroughly.
42
43 As a **personal experience** on that: after 17 weeks of RCBW (at the time of
44 writing) I haven't received a single complaint by NMU-ed maintainers, and I've
45 received several "thank you" emails. The "worst" that happened is that a couple
46 of times NMU-ed maintainers have overridden my NMUs by uploading directly to
47 unstable newer version of the involved packages: that's good anyhow, because in
48 the end bugs got fixed!, and most likely that happened *earlier* than if the
49 NMU have not been attempted. Others people that have thus far participated in
50 the RCBW "game" have enjoyed
51 [similar](http://info.comodo.priv.at/blog/archives/2009/12/#e2009-12-20T20_47_14.txt)
52 [experiences](http://info.comodo.priv.at/blog/archives/2009/12/#e2009-12-27T22_35_42.txt).
53
54 ## Work-flow
55
56 To achieve that without burning yourself, I believe you should put into use a
57 **suitable NMU work-flow**, here is mine, which is open for discussions and
58 improvement suggestions <small>(it is a version of those announced in
59 [[my first post|blog/posts/2009/09/rc_bug_of_the_day_-_again]], improved over
60 time)</small>:
61
62 1. go to <http://bts.turmzimmer.net/details.php>, filter according to your own
63    criteria (mine are
64    [here](http://bts.turmzimmer.net/details.php?bydist=both&sortby=packages&ignhinted=on&ignpending=on&ignmerged=on&ignbritney=on&ignotherfixed=on&new=7&refresh=1800):
65    they try to highlight bugs that still need to be *fixed* rather than, say,
66    transition to testing, YMMV)
67 2. choose an inspiring bug form the list which is at least 2 week old, study
68    its log; I tend to prefer neglected bug logs, where the maintainer has been
69    unresponsive
70 3. `apt-get source package` , `sudo cowbuilder --build package_1.2-3.dsc` ,
71    install the result and check for bug reproducibility (this is most useful
72    for FTBFS bugs, for others you can usually check for reproducibility
73    installing from the archive)
74 4. fix the bug ! (yes, this is the easy step :-) ), taking care of not
75    changing anything else
76 5. `dch --nmu`
77 6. `dpkg-source -b package-1.2/` ,
78    `sudo cowbuilder --build package_1.2-3.1.dsc` ,
79    check if the bug is fixed and the package otherwise working
80 7. `lintian package_1.2-3.1.changes` , check that there are no
81    regressions in lintian errors wrt latest uploaded version
82 8. `lintian -F package_1.2-3.1.changes` , if something shows up you must fix
83    it, otherwise
84    [your upload will be refused at the end of the delay period](http://lists.debian.org/debian-devel/2009/11/msg00880.html)
85 9. `interdiff -z package_1.2-3.diff.gz package_1.2-3.1.diff.gz` ,
86    check that no unexpected changes have slipped in
87 10. `debsign package_1.2-3.1*changes` , `dput -e 2 package_1.2-3.1*changes`
88    (as allowed by [devref
89    §5.11.1](http://www.debian.org/doc/developers-reference/pkgs.html#nmu-guidelines))
90 11. `nmudiff --delay 2` , in the text: briefly describe in what the
91    patch consists, and mention explicitly devref §5.11.1
92
93 ## Blog posts
94
95 As RCBW is not only a technical exercise in making Debian RC-bug-free, but also
96 in improving its internal culture about NMUs (YMMV, of course), **letting
97 others know** that you are fixing RC bugs in packages other than yours if an
98 important ingredient of the whole process. That's why I weekly blog about my
99 squashes. Note that here vanity has a little role (well, OK, it always has
100 *some* role, but here it is secondary), the goal is trying to **motivate
101 others** in doing the same as you.
102
103 Again, as a personal experience I'm happy to report that several of the people
104 which have joined RCBW over time have told me that my posts motivated them to
105 fix RC bugs. That alone would be enough of a motivation/reword for doing and
106 having done RCBW.
107
108 Below you can hence find a list of the most recent **blog posts** documenting
109 my RCBW efforts; a [[**full archive**|archive]] listing *all* of them is
110 available on a [[separate page|archive]].
111
112 [[!inline pages="blog/posts/*/*/* and !blog/posts/*/*/*/* and link(tags/rcbw)" archive="yes" show="10"]]
113
114 ## Kudos
115
116 * [Steinar H. Gunderson](http://blog.sesse.net/blog) which a few Debian
117   releases ago started fixing one RC bug per day and (micro)blogging about
118   that. RCBW has been shamelessly copied from his efforts.