On 25/10/13 10:09, Dmitrijs Ledkovs wrote:
>>> Changed-By: Andreas Moog <am...@ubuntu.com
...
> I sponsored Andreas' patch as NMU, on my own initiative.
I don't think it's appropriate to consider a patch in the BTS to be a
request for sponsorship. In future please take responsibility for the
decision to upload in the changelog, something like one of these:
away (0.9.5+ds-0+nmu2) unstable; urgency=low
* Non-maintainer upload.
[ Andreas Moog ]
* d/p/01_fix_makefile: $LIBS need to come after $SRC while
linking to fix building with ld --as-needed (Closes: #634323)
-- Dmitrijs Ledkovs <x...@debian.org> ...
or maybe
away (0.9.5+ds-0+nmu2) unstable; urgency=low
* Non-maintainer upload.
* d/p/01_fix_makefile: $LIBS need to come after $SRC while
linking to fix building with ld --as-needed (Closes: #634323).
Patch from Andreas Moog.
-- Dmitrijs Ledkovs <x...@debian.org> ...
The rule of thumb I use is that the signoff in the changelog is from the
person who decided "the package, in this exact state, should be uploaded".
In a traditional sponsored upload, the sponsored uploader puts their
name in the changelog, because they were the one to request that this
particular version, as opposed to one with more or fewer changes, was
uploaded; the DD who builds their .dsc and GPG-signs the upload merely
checks that it's of a quality that they are willing to upload.
(This means that if a non-DD co-maintainer asks me to upload a package
from Alioth git for them, I don't usually do it as a sponsored upload,
because there's nearly always something minor I want to change at the
same time...)
> I understand that
> "away" package did not even handle CFLAGS, CPPFLAGS, LDFLAGS, and
> DESTDIR until last nmu, but why not improve a package or at least
> reply to the bug report?
I started to write my understanding of best-practice for polite NMUs
here, but the devref says it better than I could:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
(tl;dr: uploading to DELAYED/10 with a nmudiff sent to the bug would be
more reasonable.)
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/526a43c6.3050...@debian.org
