On Mon, Oct 17, 2005 at 10:33:04AM +0200, Simon Richter wrote: > Steve Langasek wrote: > >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. > My personal experience with NMUs has been pretty bad. In two cases, I > needed to add cleanup code in the postinst to sort out the mess, and in > one case the package turned Debian native. One "fixed" a problem where > the optimized assembler code in the upstream package wasn't used (MMX > assembler is bad, mmmkay?) and broke all other architectures at the same > time by unconditionally enabling it. Hmm, I'm sorry to hear that. Did you report these problems to the ftpmasters at the time? They have in the past restricted developers' upload rights as a result of inappropriate NMUs. Did you bring these problems up for discussion in public? Unfortunately, when such problems are kept quiet, it makes it harder to judge whether the NMU policies are working as advertised. Were these problem NMUs done in accordance with the NMU policy at the time? I'm not sure how much we should let the rules be influenced by people who aren't *following* the rules. Of course, there's an advantage to keeping the rules simple, to improve the odds that everyone will be able to keep track of them as well. "Don't NMU unless you know what you're doing" is actually a fairly complicated rule to follow. "Don't NMU unless the patch is in the BTS first" is a much simpler one. "Don't NMU without consent of the maintainer", "don't NMU unless the patch has been in the BTS for three days", and "don't make any changes in an NMU that don't directly fix a release-critical bug" are also *simple* rules, but they also make it harder for people who *do* know what they're doing to get things done. From what I've seen, I think our experience with sarge shows pretty consistently that when you eliminate the red tape for NMUs, most people doing NMUs do know what they're doing, and a lot of good work gets done. So I definitely feel that whatever rules we adopt for etch should continue to make it easy for good NMUers to upload good NMUs. I think a good balance would be something like: - send mail to the bug with a full diff *before* uploading your package to incoming; two minutes before, two hours before, two days before, it doesn't matter - don't make any changes in an NMU that don't correspond to pre-existing reports in the BTS - don't NMU for feature requests (i.e., wishlist bugs) without the maintainer's prior approval - don't upload changes that you don't understand - don't race maintainers to their own bugs; urgent uploads are sometimes necessary, but in most cases you should give maintainers a week to deal with the bug themselves. Also see above about sending diffs to the BTS *before* uploading. This seems to catch corner cases like turning on MMX assembler on all arches; the attentive maintainer notices in less than a week that the bug filed asking for MMX is wrong/unfixable and demotes it to wishlist with a comment, and the responsible NMUer doesn't touch the wishlist bug. I don't know whether it takes care of NMUs screwed up badly enough to require postinst fixes, or if there are other corner cases not addressed. Do you have thoughts on that? > What would be Nice To Have(tm) would be a free-form text field on db.d.o > where I could state my wishes about NMUs on my packages. Which then becomes a *very* complex rule that prospective NMUers have to follow... :/ Is this kind of thing actually necessary if we are able to come up with better project-wide NMU policies? -- 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