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-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.
> > > +</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
Reply to: