NMU procedure and /usr/bin/nmudiff defaults
Hi all,
for those who don't know, nmudiff is a small script by Steinar H.
Gunderson that, when invoked in the source tree of a NMU, will create a
diff with respect the previous version, and send it to the BTS. I've
found it quite useful myself, and probably others have as well.
By default, the current version of nmudiff opens a new bug against the
package and attaches the diff to it. I recently submitted wishlist
#370056 against devscripts so nmudiff behaves like this only if --new is
passed, and by default sends the patch to the bugs the NMU fixes.
My rationale for this is that, from what I see nowadays, it's way more
common for people to just send the NMU diff to existing bugs, that to
open a new one for it (which was, I presume, much more comon in the
past).
To this Steinar agreed, but stated that what he'd really like is for a
consensus about what's the right thing to do to be reached, and document
it in the developer's reference. At the moment, section 5.11.4 only says:
| Also, after doing an NMU, you have to send that information to the
| existing bugs that are fixed by your NMU, including the unified diff.
| Alternatively you can open a new bug and include a patch showing all
| the changes you have made.
So, to summarize, I think introducing --new as non-default is a good
change, but more opinions are welcome.
(And while I wait for answers, I'll go dream about the day when dak
itself will send the diffs to the BTS, if ever.)
Thanks, relevant part of the previous discussion included below.
* Steinar H. Gunderson [Sat, 03 Jun 2006 01:58:07 +0200]:
> On Sat, Jun 03, 2006 at 01:51:49AM +0200, Adeodato Simó wrote:
> > However, while opening a new bug to submit a NMU diff has been the
> > traditional approach, nowadays I really think it's more common to send
> > the diff to the bugs fixed by the NMU. So I hacked a copy for my ~/bin
> > changing that, but then I thought why not submit it, etc., and here I
> > am.
> Yes, I recognize that; however, I don't like the approach when there are
> multiple bugs involved. OTOH, this is a bit of a personal issue, and as you
> say, the method of not opening a separate bug might be more common these
> days.
> Actually, I think what _should_ be done on this, is to establish some kind of
> consensus on what's the right thing to do, document it in the developer's
> reference and then decide on the default. This is especially true since
> what's "right" yesterday might not be "right" today or tomorrow, with the BTS
> gradually getting full version tracking (so, the need to actually track bugs
> fixed in NMUs this manual way would completely go away). I'm not sure what
> the future holds here, and I'd like to get some input on it from someone
> more knowledgeable before this goes in.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
British policemen don't wear guns. If they're chasing someone, they
yell, "Stop! Or I'll yell stop again".
-- Robin Williams
Reply to: