On Tuesday, April 24, 2012 03:46:59, Lucas Nussbaum wrote: > Hi, > > Adding zack to Cc. Cool. > Note that this discussion should really take place in a public place. > Maybe in a bug report? Huh... I was going to ask where to do that, but I just realized the existence of the 'developers-reference' package, so I could file a wishlist bug in the BTS for the package. Yeah I think that's a good idea. > On 24/04/12 at 02:50 -0400, Chris Knadle wrote: > > On Monday, April 23, 2012 18:54:41, Lucas Nussbaum wrote: > > > On 23/04/12 at 17:24 -0400, Chris Knadle wrote: ... > > > > 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. > > I don't think that what the DPL stated in that thread is fundamentally > different from what is described in dev-ref. Also, note that the DPL was > expressing his opinion, and that, because the DPL expresses an opinion, > it does not necessarily become the opinion of the project. :-/ I'm *not* at all trying to say "the DPL is the authority". I'm saying that what Zack wrote about NMUs makes a lot more logical sense to me than what's in section of 5.11.1 of the Dev Ref right now. > > > > - 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. > > Seriously, if the dev-ref states: > > Fixing cosmetic issues or changing the packaging style in NMUs is > > discouraged. > > And you understand: > > the NMU package shouldn't make any changes other than some time of > > critical bug fix > > I don't know how I can help you. Short single sentence replies of "you are <blah>" is geek speak for "I'm not interested in what you're saying", so I was trying to get you to consider how you were communicating. I've tried to explain the disparity between the impression I get from Section 5.11.1 verses the impression I get from Zack concerning NMUs, and I'm saying the two impressions don't match in ways I think are significant. I think you might be misunderstanding that the OVERALL TONE of the entire section is part of the issue. Anywhere statements are vague, the tone can alter the meaning. I listed the sentence as an example of the tone. Nitpicking my interpretation of the one sentence alone misses the point. > Fixing minor bugs or wishlist bugs in an NMU are OK. Basically, what > should not be done in the general case is making decisions, opposite to > the maintainer's own choices, that are mainly a matter of taste. > For exammple, switching from cdbs to dh (without the maintainer's > approval). The above makes complete sense, but that's not what the section of the Dev-Ref says; it simply says "changing packaging style is discouraged", but not what "packaging style" means. For instance, say a potential maintainer picks up an old package to do an NMU on, and updates the version of debhelper from v5 to v8, switches from 1.0 format to 3.0 quilt format, and likewise has to make numerous other similar tweaks both to the debian files and patching the upstream source. Are any of these possibly considered part of packaging style in terms of this section of the Dev Ref? Part of the problem is vocabulary re-use; for instance "a bug" has all kinds of specific contexts, so when there's no hint as to the context, it's easy to misconstrue the actual meaning. The result is that "packaging style" has a different meaning than "packaging style (dh_, cdbs, etc)" does. > > > > 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. > > The team's opinion does not really matter. dev-ref aims at capturing > and documenting the consensus inside the project. The hard part of the > task is to understand where lies that consensus. Last time that > discussion was held, ghost DDs that did not do any work for the last 5 > years woke up and started arguing that NMUs are evil. Ahhh... ooookay. Thanks, the above information helps me understand the role of the Dev-Ref team. Sorry you guys had to go through that re: dormant DDs and "evil" -- I overheard some of this sentiment during DebConf10. Frustrating. > So the question is: is it worth it? The NMU policy could probably be > improved, but not without long+heated discussions. I think the current > state of the NMU policy does not require to do that work now. If you > want to do it, I would suggest to do the following: > - prepare a patch to dev-ref that reflects what you think consensus is > - ask for a DEP number > - start a discussion on -devel@, following the DEP procedure > (that's what was done last time) > Of course, dev-ref will integrate the result of the process, provided > the process is properly carried out. Hah! I see what you mean. ;-) Well, okay, that at least gives me a direction for the correct proceedure -- that's cool. Probably the next logical step is for me to take would be to file a wishlist bug on the developers-reference package, which will at minimum capture my ideas for improving the wording of the section to make it a bit more explicit. At least this way if it's not worth modding the document now, the next time it's done the wishlist bug will exist for consideration. > > 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. ;-) > > Thanks :) Thanks for taking the time to write back. :-) -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Attachment:
signature.asc
Description: This is a digitally signed message part.