Re: Proposal to update NMU section 5.11.1
Hi,
Adding zack to Cc.
Note that this discussion should really take place in a public place.
Maybe in a bug report?
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:
> > > 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.
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.
The current policy on NMUs was defined after long and heated
discussions (please read them to get an idea). It is a compromise
between various positions.
> > > - 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.
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).
> > > 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.
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.
> 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 :)
- Lucas
Reply to: