On Monday, April 23, 2012 18:54:41, Lucas Nussbaum wrote: > 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. I now that *now*, but only because of discussion on [debian-devel], and not because of Section 5.11 of the Developer's Reference. :-( Let me state the issue another way -- when it comes to NMUs, my personal reference on them is now Zack's email, and not the Developer's Reference. :-/ I want others to be able to get at least the same level of understanding of NMUs that I currently have now after discussing it on [debian-devel], without having the DPL needing to repeatedly explain them. > > - States that leaving an open grave bug might be better than possibly > > uploading a version that breaks something else > > that's correct Try to read between the lines -- it implies "be reluctant to do an NMU unless you're absolutely sure of what you're doing". That's a much higher bar than the spirit that I think is embodied in Zack's email describing NMUs. And there's a difference between being correct and being informative. i.e. just because a statement is correct doesn't mean it conveys what DDs need to know. > > - 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. Saying this is not helpful. > > 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. I'm not discouraged -- if anything I'd expect the reverse. Due to the effort it took to create the document, a common result would be if the team were reluctant to change the document unless there's a blatently obvious reason to do so. My goal (at least to start with) was to convey the issue to see if I could motivate doing something about it. There is merit in the attempt regardless, so if ultimately nothing changes, that's okay. P.S. I really appreciate your Debian packaging tutorial. ;-) -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Attachment:
signature.asc
Description: This is a digitally signed message part.