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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120423225441.ga7...@xanadu.blop.info
