[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from the release team: the plans for etch

[Let's please keep this discussion on debian-devel, as debian-release is not
a discussion list, and not exactly widely followed either]

On Sun, Oct 16, 2005 at 10:28:33AM +0200, Roland Stigge wrote:

> Steve Langasek wrote:
> > NMU policy
> > ~~~~~~~~~~
> > After lots of experimentation with NMU policies during the sarge release
> > process, it's pretty clear that permissive NMU policies had a HUGE,
> > positive impact on our ability as a project to cope with outstanding
> > release-critical issues.  We don't want that to stop now just because
> > the sarge release is behind us; NMUs don't just speed up the release,
> > they're also great for helping the quality of Debian!  For this reason,
> > we would like to continue the 0-day NMU policy from sarge throughout the
> > etch release cycle.  But first, we'd like to hear from you, the
> > developers, about what *you* thought did and didn't work with NMUs for
> > sarge.

> 0-day NMUs are fine, as long as it is emphasized that it's only
> appropriate if the usual maintainer doesn't work on the issue. I.e. you
> either need to try to contact the developer or only operate on
> reasonably "old" bugs; better both.

It's easy to understand why people are opposed to too-frequent NMUs.  They
don't want to be seen as bad maintainers for having too many NMUs on their
packages; they worry about new bugs being introduced in the process; they
worry about sloppy fixes hiding bugs and preventing proper fixes from taking

But let's look at the specific example that you brought up:

> Otherwise things like

>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308406

> will happen more often, and I expect even more stupid things. As seen in
> this example, we also need to stress that NMUs must be done with special
> care and responsibility. And the NMUer needs to be sufficiently skilled
> to work on packages otherwise unknown to him.

So here's the order of events in 308406:

- an RC bug is filed about a missing package dependency during the sarge
  freeze, leaving fairly little time to fix the package for sarge
- three days later, a developer uploads an NMU which fixes this bug (good),
  but also makes a change unrelated to the RC bug and in the process breaks
  the package's build-dependencies (bad)
- the maintainer notices (good), and does his own upload later that day
  which restores the package's previous subtly-buggy behavior (?)
- the package releases with sarge (good)

So was the NMU a net win or loss for Debian?  Would this answer be different
if the NMU had made it into sarge instead of being superseded by the

In both scenarios, I think the NMU in question is a net win for Debian.  In
this specific case, the NMU may have turned out to be *unnecessary*, but
there's no way to know this beforehand, and it's hard even for anyone other
than the maintainer to know it after the fact either as the NMU may have
prompted the MU.  Anyway, the bug that the NMU fixed was release-critical;
the choices were to NMU the package, or wait around and hope that the
maintainer will fix it before the package is dropped from testing (and, at
that point in time, the release).  So even if perfect hindsight suggests it
would have been more efficient not to bother with the NMU, if the
alternative to NMUing is sitting around worrying about whether the
maintainer will upload, well, that's not a clear win even if the maintainer
does do an upload later.

As for the specific content of this NMU: the NMUer fixed a missing
dependency that would prevent users from being able to install the package.
In the process, a change was made that moved all of the build-depends to
Build-Depends-Indep.  This is incorrect, because policy does not require
B-D-I to be satisfied in the clean target and musixtex-slurps uses debhelper
in the clean target.  However, the impact is negligible because
musixtex-slurps builds a single arch: all package, which means the package
will never be autobuilt in an environment which expects to call the 'clean'
and 'binary-arch' targets without also calling the 'binary' target.  And
since the source package already violates policy by building the arch: all
package in the binary-arch target instead of the binary-indep target, one
more policy infraction doesn't make much difference: IMHO, Debian would have
been better off shipping musixtex-slurps_92a-2.1 than not shipping
musixtex-slurps at all.

Was it wrong to make that change in an NMU?  Sure.  Would it have hurt us if
that change had made it into a stable release?  Not really.  Should we be
worried about NMUs of poor quality hindering development?  IMHO, no -- not
based on this example.

Now, more compelling would be an example of a bad NMU that did make its way
into a stable release, and was *more* broken than the bug it was trying to
fix.  Can anyone offer an example like that?

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: