[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NMU procedure and /usr/bin/nmudiff defaults



Adeodato Simó wrote:
> Hi all,

Hi

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

Yes, indeed!

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

I always thought sending the patch to existing bugs is better... Though
opening a new bug when NMUing has the advantage that more maintainers
explicitely acknowledge NMUs instead of just use the NMU, but letting
the respective bugs being tagged fixed without closing them.

> So, to summarize, I think introducing --new as non-default is a good
> change, but more opinions are welcome.

I do think the option of just sending the patch to existing bugs is
required and in many cases even preferred.

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

I can understand it especially after having opened a new bug when NMUing
for some time now...

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

I do think that both options (sending patches to existing bugs and
opening a new bug) are appropriate, though I dislike not sending any
comment to an existing bug report when the package is uploaded to the
(not zero days) delayed queue or when the package enters the NEW queue.
Because of this some people might prefer to send the patches to existing
bugs when NMUing even if there are many bugs involved...

To summarize: I would like the patch to be applied and I propose to not
change the existing wording about NMU practice (at least not excluding
one of the two existing options).

Cheers

Luk

PS: As a sid note, I would like people to also have a look at the l10n,
documentation and porting bugs (at least) when NMUing for RC bugs...

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: