WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
Oops... sending again, as I forgot to CC: the developer's reference team.
On Monday, April 23, 2012 16:26:59, Lucas Nussbaum wrote:
> 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". 
> > 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 . If
> > you browse the 'wine' source package at , 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  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  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.
- 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.