On 03/03/14 13:43, Dimitri John Ledkov wrote:
> [*] imho preparing an NMU debdiff _is_ asking for it to be uploaded...
There's a significant difference between these possible reasons to send
a diff to a bug:
* I made a change, I'm confident that it's right, and I'm going to (NMU
it|ask for a sponsor) if nobody specifically tells me not to
* I made a change, it seemed to work for me, but I don't know enough
about the package to know whether it's the right fix; review, please?
or even
* I hacked around it in a way that works on my system; presenting it
for comment, but I'm pretty sure it's wrong
The easiest way to get a patch onto a bug for any of those reasons is
edit, dch, build, nmudiff. I wouldn't want to make it any harder than
that to get a diff on a bug, even the submitter knows it's a workaround
- looking at a working workaround is often a good step towards a more
correct solution, and if someone is doing a drive-by workaround or
bugfix in order to make something work on their own machine so they can
get on with their life, the likely alternative if it's any harder is
that the change never leaves their hard disk at all.
Before the dch(1) default changed to
DEBCHANGE_RELEASE_HEURISTIC=changelog in wheezy, the distribution would
probably be set to "unstable" for any of those reasons, making it harder
to tell which one the patch author intended.
Now that stable's devscripts default to
DEBCHANGE_RELEASE_HEURISTIC=changelog, it is more likely that someone
attaching nmudiff output to a bug with the distribution set to unstable
(e.g. with "dch -r" as Russ implied) is in fact asking for it to be
uploaded as-is, because if they hadn't intended it to be uploaded, they
would probably have left it saying UNRELEASED.
In my opinion, the "signature" ("trailer" in dch terminology) should
come from the developer who thought "this exact version is what should
be in unstable now"; but it's difficult to determine intent
mechanically. If in doubt, the safe assumption is that the patch
submitter wasn't sure about it, and that the reviewer is the one taking
responsibility for deciding that it should be uploaded.
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
