Re: Proposal to update NMU section 5.11.1
On 23/04/12 at 17:24 -0400, Chris Knadle wrote:
> 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.
wishlist bugs are bugs, so they are covered.
> - States that leaving an open grave bug might be better than possibly
> uploading a version that breaks something else
that's correct
> - 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."
You are over-reading.
> 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.
I don't mean to discourage you, but converging on the current wording
took several hundreds of mails. See http://dep.debian.net/deps/dep1.html
and related discussions on various mailing lists back in 2008.
Lucas
Reply to: