RCBW - week #12

Here is this week squashes, by yours truly:

• 23/11/2009 Debian bug #553122 - libtcl-chiark-1 - add missing ldconfig invocation, for *.so in linker locations
• 24/11/2009 Debian bug #528152 - tulip - replace ttf-bistream-vera w/ dejavusans (patch from James Westby)
• 25/11/2009 Debian bug #533993 - solfege - remove net need for xmllint (patch from Ubuntu by Alessio Treglia)
• 26/11/2009 Debian bug #531220 - nut - fix ntp.conf postinst processing to avoid overwriting user settings
• 27/11/2009 Debian bug #523912 - mit-scheme - add missing build-dep + tricky build due to bootstrap
• 28/11/2009 Debian bug #521964 - libapache2-mod-lisp - fix APR version detection, patch by Antonio Radici
• 29/11/2009 Debian bug #553257 - pidgin-hotkeys - remove unappropriate e-Xclusion in dh_shlibdebs

The funniest part of this RCBW issue is probably that Luk has started handing over RC bugs to me: from time to time I just get a /query from him with bug numbers

In fact, this is more useful than one can imagine, because a considerable amount of time in periodic RC squashing is taken by triaging the RC bug list to choose your targets. Of course there is no guarantee that I'll be willing/able to fix handed-over bugs but, as a RM, Luk has evidently well-trained feelings about how hard would be to fix a given bug. All in all, for this week it worked well: 4 of the above 7 came from SchindlerLuk's list.

... and of course, let's welcome Simon on board! He is definitely doing a better job at spotting packages that should be removed from the archive rather than resurrected (potential negative effect that a NMU can indeed have on a package, de facto "saving" it from testing/release exclusion).

In fact, the dilemma of "NMU vs Request Removal" raises various tricky questions. For instance, while we currently have pretty clear guidelines on how and, more importantly, when doing NMUs, we are more stringent on "Non-Maintainer Removals". Quoting from the Package Removal Requests wiki page:

    In all cases, if there is a maintainer and it's not you, mention the
    maintainer's opinion or, if you don't know it, mention how and when you
    tried to contact him.

It is of course reasonable to be more stringent on a measure that is way more invasive than a "simple" NMU. But if we start to rely on NMU-time as an important trigger for removal requests, then we could probably use a more aggressive and more distributed process for removals.