add some real content to the RCBW description page
authorStefano Zacchiroli <zack@upsilon.cc>
Mon, 4 Jan 2010 16:13:30 +0000 (17:13 +0100)
committerStefano Zacchiroli <zack@upsilon.cc>
Mon, 4 Jan 2010 16:13:30 +0000 (17:13 +0100)
hacking/debian/rcbw.mdwn

index 1aba211..6200e29 100644 (file)
 
 This page documents the **RCBW initiative** (for **Release Critical Bugs of the
 Week**) that [[I've started|blog/posts/2009/09/rc_bug_of_the_day_-_again]] in
 
 This page documents the **RCBW initiative** (for **Release Critical Bugs of the
 Week**) that [[I've started|blog/posts/2009/09/rc_bug_of_the_day_-_again]] in
-September 2009..
+September 2009.
 
 
-I'll eventually add some *motivations* / *background material* about that, for
-now here you can just find references to my periodic RCBW posts.
+The basic idea is very simple: since Debian accumulates a lot of
+[RC bugs](http://bugs.debian.org/release-critical/) 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 can then work on the most
+  difficult/specific ones
+- relatively **quick**: I haven't actually timed myself, but I'd say 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 will discover and learn many new packages, packaging
+  techniques, packaging tools, programming languages, ...
 
 
-Below you can find a list of the most recent **blog posts** documenting my RCBW
-efforts; a **[[full archive|archive]]** listing *all* of them is available on a
-[[separate page|archive]].
+On these topics I'll avoid stressing the very good explanations (and tricks)
+provided by Steve Langasek in his excellent
+[RC bug squashing primer](http://people.debian.org/~vorlon/rc-bugsquashing.html);
+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**](http://www.debian.org/doc/developers-reference/pkgs.html#nmu-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 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 bugs got fixed!, and most likely that happened *earlier* than if the
+NMU have not been attempted. Others people that have thus far participated in
+the RCBW "game" have enjoyed
+[similar](http://info.comodo.priv.at/blog/archives/2009/12/#e2009-12-20T20_47_14.txt)
+[experiences](http://info.comodo.priv.at/blog/archives/2009/12/#e2009-12-27T22_35_42.txt).
+
+## 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 <small>(it is a version of those announced in
+[[my first post|blog/posts/2009/09/rc_bug_of_the_day_-_again]], improved over
+time)</small>:
+
+1. go to <http://bts.turmzimmer.net/details.php>, filter according to your own
+   criteria (mine are
+   [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):
+   they try to highlight bugs that still need to be *fixed* rather than, say,
+   transition to testing, YMMV)
+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](http://lists.debian.org/debian-devel/2009/11/msg00880.html)
+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](http://www.debian.org/doc/developers-reference/pkgs.html#nmu-guidelines))
+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**|archive]] listing *all* of them is
+available on a [[separate page|archive]].
 
 [[!inline pages="blog/posts/*/*/* and !blog/posts/*/*/*/* and link(tags/rcbw)" archive="yes" show="10"]]
 
 [[!inline pages="blog/posts/*/*/* and !blog/posts/*/*/*/* and link(tags/rcbw)" archive="yes" show="10"]]
+
+## Kudos
+
+* [Steinar H. Gunderson](http://blog.sesse.net/blog) 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.