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

Re: Proposal to update NMU section 5.11.1



Oops... sending again, as I forgot to CC: the developer's reference team.

On Monday, April 23, 2012 16:26:59, Lucas Nussbaum wrote:
> Hi,
> 
> On 23/04/12 at 14:56 -0400, Chris Knadle wrote:
> > Greetings.
> > 
> > I would like your consideration as to whether to update Section 5.11.1 of
> > the Developer's Reference to incorporate some of the views of Stefano
> > Zacchiroli concerning "When and how to do an NMU".  [1]
> > 
> > For background as to why this came up, there's recently been discussion
> > about several packages in Debian that are quite out of date compared to
> > upstream, including the WINE packages -- this thread starts at [2].  If
> > you browse the 'wine' source package at [3], you can see what has
> > transpired: there used to be several people collaborating on the wine
> > packages, but for whatever reason it ended up being left to only one
> > maintainer doing the work.  This maintainer has stated [4] that he has
> > time overloaded elsewhere so that he doesn't have time to work on the
> > packages now, but simultaneously has QA requirements such that all of
> > the older pre-1.2 wine versions must be packaged first before packaging
> > versions 1.2 and 1.4.
> > 
> > It seems like NMU(s) on the package(s) would be a reasonable course of
> > action, but the current wording of Section 5.11.1 in the Developer's
> > Reference [5] would seem to discourage this -- or at least that's how I
> > personally interpret the current wording.  This is the reason I would
> > like to revisit this issue to see whether updating the wording in this
> > section would be appropriate.
> 
> Could you be a bit more specific about what you believe is not allowed
> to do using NMUs?

Not exactly, no -- the reason is that section 5.11.1 doesn't state what isn't 
allowed with NMUs, and instead seems worded on the conservative side and 
simply makes recommendations of when NMUs might be appropriate or not.  In 
other words, I think the section is a little too vague, and simultaneously 
doesn't seem to correspond with what Zack believes can be done with NMUs.

Section 5.11.1:

- Seems to imply that the only reason to do an NMU is for fixing bugs.  In 
interpreting this, it is not clear that a wishlist bug report of "please 
package the new upstream version" is something that could be valid to do an 
NMU for if the maintainer doesn't have time to do the work.

- States that leaving an open grave bug might be better than possibly 
uploading a version that breaks something else

- Implies that the NMU package shouldn't make any changes other than some time 
of critical bug fix -- quoting: "Fixing cosmetic issues or changing the 
packaging style in NMUs is discouraged."



Quite literally what happened in this case is Zack pointed me to read Section 
5.11.1 of the Developer's Reference, along with saying that NMUs are more 
permissive than I thought they were -- and after reading the section again, I 
came back with the same conclusion that I already had because of the way it's 
worded.  I'm hoping to reword the section so that others don't get the same 
mistaken impression that I had, which was that Debian Developers generally 
don't do NMUs unless it's for an Release Critical bug of some kind, and never 
to do NMUs for uploading a new upstream version.  I'm not the only one that 
had this mistaken impression.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: