On Tue, Sep 29, 2009 at 11:46:59AM -0400, James Vega wrote: > In #370056 and debian-devel[0] the proposed change of default behavior > from "file a new bug" to "follow-up to the existing bug(s)" was > discussed. There was definite agreement about performing a followup > for an NMU that fixes one bug but differing opinion for one that > closes multiple bugs.
OK, thanks for the pointer, too bad I missed the discussion back then. Still, I don't see that "definite agreement" in the current default (well, not from the mailing list archive, it might have been discussed elsewhere, e.g. on IRC of course). In that thread, the distinction between one and more bugs is mentioned only in two leaf messages [1,2] and both are very hypothetical about the distinction. The only semi-argument is from [2] and is just a concern about duplicating the patch. My argument for having a uniform default is not about duplication (which doesn't seem a problem at all to me), but about workflow considerations. Since you replied on the same lines, I believe we can decide on top of that. [1] http://lists.debian.org/debian-devel/2006/06/msg00175.html [2] http://lists.debian.org/debian-devel/2006/06/msg00182.html > Either way, you have to spend time understanding the intent of the > mail you get. With a new bug, you get a single piece of information > to handle: Joe NMUer sent me a patch to fix bugs X, Y, and Z. With a > followup to all bugs involved, you'll receive one email per bug, all > containing the same information. De-duplication of the patch was one > of the reasons for filing a new bug when multiple bugs are fixed by an > NMU and I fail to see how handling one email instead of N is harder to > handle. The N emails are identical (actually, duplicates). Receiving duplicate emails from the BTS is not a new pattern, it happens for instance when someone mails both the bug log and the maintainer directly (e.g., because he is replying to a previous message). We all know how to deal with that and most MUAs offer countermeasures against that. > When the NMU is accepted into the archive the people subscribed to the > bug report will be notified about the fix via the automatic "bug > closed" message. Submitting a new bug to notify the maintainer about > your patch that fixes N bugs in no way affects the notification of the > submitters/subscribers to those N bugs that their problem is fixed. > > Notifying the subscribers that there is a patch for the bug is a "nice > to have" but isn't required in the case of an NMU, IMO, especially > since the subscribers will soon have a fixed package to install. I > think it's more relevant when there isn't an imminent upload. Uhm, OK, here we have a misunderstanding because I failed to clarify my use case in the former message. I'm mainly concerned about DELAYED NMUs. They are becoming more and more common and they are actually *the* recommended way of NMU-ing according to devref, 0-days NMU are allowed basically near to releases and are the exception rather than the rule. In the DELAYED NMU scenario things change quite a bit wrt your arguments. In that case NMU upload and followers notifications happen at different times. If nmudiff opens a new bug, followers are not notified until the upload hits the archive. While this can look as a minor loss, it can actually help the maintainer (or other followers) to dcut-away broken NMUs if they spot them before the DELAYED period expires. In my eyes that is enough to justify a more uniform default for --old, ... but also the current non-uniform (and puzzling at first!) behavior is a good justification. Thanks for this interesting discussion! Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
