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

NMU policies for etch [Was: Re: Bits from the release team: the plans for etch]

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

Reply to: