Bug#593611: Clarify whose signature should go in debian/changelog (4.4)
On 30 July 2014 14:08, Bill Allombert <ballombe@debian.org> wrote:
> On Mon, Mar 03, 2014 at 02:24:23PM +0100, Bill Allombert wrote:
>> On Sun, Dec 25, 2011 at 10:46:18AM -0800, Russ Allbery wrote:
>> > Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
>> > > On Sat, Sep 18, 2010 at 09:10:58PM -0700, Russ Allbery wrote:
>> >
>> > >> --- a/policy.sgml
>> > >> +++ b/policy.sgml
>> > >> @@ -1688,11 +1688,14 @@
>> > >>
>> > >> <p>
>> > >> The maintainer name and email address used in the changelog
>> > >> - should be the details of the person uploading <em>this</em>
>> > >> - version. They are <em>not</em> necessarily those of the
>> > >> - usual package maintainer.<footnote>
>> > >> - If the developer uploading the package is not one of the usual
>> > >> - maintainers of the package (as listed in
>> > >> + should be the details of the person who prepared this release of
>> > >> + the package. They are <em>not</em> necessarily those of the
>> > >> + uploader or usual package maintainer.<footnote>
>> > >> + In the case of a sponsored upload, the uploader signs the
>> > >> + files, but the changelog maintainer name and address are those
>> > >> + of the person who prepared this release. If the preparer of
>> > >> + the release is not one of the usual maintainers of the package
>> > >> + (as listed in
>> > >> the <qref id="f-Maintainer"><tt>Maintainer</tt></qref>
>> > >> or <qref id="f-Uploaders"><tt>Uploaders</tt></qref> control
>> > >> fields of the package), the first line of the changelog is
>> >
>> > > As I said earlier, I do not think that this matches current practices.
>> >
>> > > As I see current practices:
>> > > 1) the name in the changelog in the one of whoever ran dch last,
>> > > i.e. the name of the developer who changed the date in the changelog
>> > > last.
>> >
>> > > 2) Someone sponsoring a package does not change it in any way.
>> >
>> > > Maybe this kind of information are better placed in the developer
>> > > reference than in policy.
>> >
>> > Hi Bill,
>> >
>> > Your objection here is I think the only thing left to deal with to resolve
>> > this bug, since the patch has otherwise been seconded. As Raphaël pointed
>> > out, I didn't intend a substantive difference between "preparing the
>> > release" and "making the last change"; whoever does the equivalent of dch
>> > -r is what's meant. Do you think this is unclear enough that I shouldn't
>> > merge the patch? I'm inclined to merge the patch since I think we're
>> > falling into the trap of scrutinizing the wording too closely.
>> >
>> > I agree that the details that you describe should probably be in the
>> > developer reference rather than in Policy, which is why I'm trying to keep
>> > this as succinct and short as possible while still addressing the original
>> > bug, which correctly points out that the current Policy wording implies
>> > that sponsors of packages should replace the changelog footer with their
>> > own identity (definitely not existing or recommended practice).
>>
>> It is clear we agree on the fundamental issues, so I will trust your judgement
>> on the wording. I am always concerned that removing one ambiguity will introduce
>> another.
>
> Russ, should I apply your patch even after Dimitri comment about sponsored NMU ?
>
Imho, we should be making it less ambigious and adjusting our
generated changes and/or debian/changelog to more team maintained
workflows:
We should unambigiously document:
Maintainer: Typically team (list of names)
Uploads: Typically a subset of team members (list of names)
Changed-by: everyone who contributed changes in this upload (list of names)
Signed-by: person who signed and dput (single uid fingerprint, not
sure we support multi-signed uploads)
GPG Signature itself, should match fingerprint of Singed-by uid
The format of debian/changelog at the moment enforces only one name
and it has no mapping to expose all people involved.
"multi-maintainer changelog" convention of using [ Name [<email>] ] is
good, but is still currently defeated by current single sign-off line
which propagates to Changed-by.
--
Regards,
Dimitri.
Reply to: