Bug#672198: [developers-reference] NMU clarification for section 5.11.1

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-deve...00486.html
> >
> >
> > Chris Knadle
> >
> >
> > 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.

> > +</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.

> 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.

Lucas



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

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-deve...00486.html
> > >
> > >
> > > Chris Knadle
> > >
> > >
> > > 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 Knadle


name="01-NMU-5.11-clarification_a.patch"
filename="01-NMU-5.11-clarification_a.patch"

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>




To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact