[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 place. 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 maintainer? 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