Bug#672198: [developers-reference] NMU clarification for section 5.11.1
On Friday, May 11, 2012 03:20:41, Lucas Nussbaum wrote:
> On 10/05/12 at 17:31 -0400, Chris Knadle wrote:
> > Sending again as I forgot to CC the BTS
> >
> > On Thursday, May 10, 2012 10:26:44, Lucas Nussbaum wrote:
> > > On 08/05/12 at 20:11 -0400, Chris Knadle wrote:
> > > > Package: developers-reference
> > > > Version: 3.4.7
> > > > Severity: wishlist
> > > > Tags: patch
> > > >
> > > > In a long email thread on [debian-devel] concerning a package which
> > > > has a maintainer that is temporarily MIA due to being time
> > > > overloaded, the discussion came to an idea for using NMUs in order
> > > > to bring the package up to date to upload a new upstream version of
> > > > the software. I was directed to read section 5.11 of the
> > > > Developer's Reference, but it doesn't seem to clearly state that
> > > > this is allowed. Stefano Zacchiroli responded with a post [1]
> > > > explaining NMUs from his point of view which I find is a bit more
> > > > clear in this area.
> > > >
> > > > Attached is a minimal patch against commit:
> > > > r9201 | taffit | 2012-04-25 09:25:10 -0400 (Wed, 25 Apr 2012)
> > > >
> > > > in the repository for the Developer's Reference. Diffstat:
> > > > pkgs.dbk | 11 +++++++++--
> > > > 1 file changed, 9 insertions(+), 2 deletions(-)
> > > >
> > > > [1] http://lists.debian.org/debian-devel/2012/04/msg00486.html
> > > >
> > > > -- Chris
> > > >
> > > > --
> > > > Chris Knadle
> > > > Chris.Knadle@coredump.us
> > > >
> > > > diff --git a/pkgs.dbk b/pkgs.dbk
> > > > index af8bcf0..6959ac8 100644
> > > > --- a/pkgs.dbk
> > > > +++ b/pkgs.dbk
> > > >
> > > > @@ -1923,8 +1923,15 @@ Before doing an NMU, consider the following
> >
> > questions:
> > > > <itemizedlist>
> > > > <listitem>
> > > > <para>
> > > >
> > > > -Does your NMU really fix bugs? Fixing cosmetic issues or changing
> > > > the -packaging style in NMUs is discouraged.
> > > > +Will the NMU help the maintainer?
> > >
> > > How do you determine that?
> >
> > As Stefano mentioned, it's a question for the submitter to consider.
> >
> > "Years ago, I've been applying the above commonsense principles while
> > performing several NMUs and I've never received harsh replies in
> > response. That experience has convinced me that properly done NMU are
> > just welcome and that to properly do NMU you just need to keep in
> > mind that the goal is helping the maintainer and use commonsense."
>
> Still, "helping the maintainer" sounds like a concept that is difficult
> to instanciate. That might require asking the maintainer, which goes
> against the idea of using the DELAYED queue for a "fire and forget"
> NMU.
Yes I agree that this is confusing to explain. Maybe this can be worded more
like "Have you geared the NMU towards helping the maintainer?"
I also agree that this is difficult to instantiate to give an example of what
this means in a particular context. Mainly I'm trying to plant the idea that
NMUs can actually help the maintainer, and that it's also a good idea to keep
helping the maintainer in mind when making an NMU.
BTW I originally worded this section as a longer paragraph and included
discussing the DELAYED queue, but removed it because it would repeat the
discussion about the DELAYED queue that is already in the document. I think
you're right that it's better to discuss it here, so I'm adding Stefano's
comments on that back into the patch. [Mainly because I don't know how to
word it any better than he has already.]
> > > > +</para>
> > > > +</listitem>
> > > > +<listitem>
> > > > +<para>
> > > > +Does your NMU really fix bugs? ("Bugs" includes wishlist bugs for
> > > > packaging +a new upstream version, but care should be taken to
> > > > minimize the impact to +the maintianer.)
> > >
> > > So other kind of wishlist bugs are not included?
> >
> > I think at least ONE example of what "bugs" means would be helpful.
> > Perhaps adding the word "even" before "wishlist bugs" would clarify
> > this.
>
> note that in your wording, "new upstream version" are the only kind of
> wishlist bugs where NMUs would be allowed, not an example of appropriate
> wishlist bugs.
I agree and that's why I've been trying to word it differently.
Changed to:
("Bugs" means any kind of bugs, e.g. wishlist bugs for packaging
a new upstream version, but care should be taken to minimize the
impact to the maintainer.)'
> > > typo: maintianer.
> >
> > Got it.
> >
> > > > +Fixing cosmetic issues or changing the packaging style
> > > > +(dh, cdbs, etc) in NMUs is discouraged.
> > >
> > > rewrite to:
> > > changing the packaging style (e.g. switching from cdbs to dh) is
> > > discouraged.
> >
> > agreed.
> >
> > Would you like an amended patch?
>
> Yes, so that keep a reasonable view of the current status of the patch.
Okay. Updated and attached.
Thanks.
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
diff --git a/pkgs.dbk b/pkgs.dbk
index af8bcf0..c4f3d1d 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1923,8 +1923,20 @@ Before doing an NMU, consider the following questions:
<itemizedlist>
<listitem>
<para>
-Does your NMU really fix bugs? Fixing cosmetic issues or changing the
-packaging style in NMUs is discouraged.
+Have you geared the NMU towards helping the maintainer? As there might
+be disagreement on the notion of whether the maintainer actually needs
+help on not, the DELAYED queue exists to give time to the maintainer to
+react and has the beneficial side-effect of allowing for independent
+reviews of the NMU diff.
+</para>
+</listitem>
+<listitem>
+<para>
+Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
+wishlist bugs for packaging a new upstream version, but care should be
+taken to minimize the impact to the maintainer.) Fixing cosmetic issues
+or changing the packaging style (e.g. switching from cdbs to dh) in NMUs
+is discouraged.
</para>
</listitem>
<listitem>
Reply to: