Re: BTS and unreleased changelog entries
Ross Vandegrift <ross@kallisti.us> writes:
> On Mon, Oct 16, 2017 at 11:54:20AM +1100, Ben Finney wrote:
> > Ross Vandegrift <ross@kallisti.us> writes:
> > > Good question. I guess I think of a changelog as history - so changes
> > > I made on 1.15 go with 1.15 whether it was released or not.
> >
> > Thanks for explaining your perspective.
> >
> > That perspective, I think, does not match the stated purpose for the
> > Debian package changelog: to inform *recipients* of the package about
> > changes between *releases* of that package.
Ross is correct in his implication that this is not easy to find stated
explicitly.
I find it to be a corollary of the Policy section about upload control
files:
"Changes"
This multiline field contains the human-readable changes data,
describing the differences between the last version and the current
one.
[…]
The value of this field is usually extracted from the
"debian/changelog" file […]
That implies that, to work correctly in the upload control file
“Changes” field, the ‘debian/changelog’ entries should “describ[e] the
differences between the last [uploaded] version and the current one” —
otherwise, it is significantly more difficult to “extract [this
information] from the "debian/changelog" file”.
In other words: write ‘debian/changelog’ entries on the assumption that
this is your most straightforward way to auto-populate the “Changes”
field when it comes time to upload a release of the package.
I fully acknowledge this requires taking Debian Policy as a whole, it
doesn't exactly jump out at the casual reader.
> I vaguely remember looking at other packages for guidance. I probably
> found plenty of examples: grepping for unreleased versions in
> /usr/share/doc/*/changelog.Debian.gz find a few hundred hits on my
> laptop.
Yes, there are many packages in Debian that don't conform very well to
Policy recommendations :-)
The Policy document also recommends that one not go back and modify
already-released package changelog entries, so those mistakes tend to
increase over time.
> > For already-released versions you will need to deal with closing
> > those bugs manually anyway.
>
> Others in this thread have said that an upload with dpkg-genchanges -v
> will trigger the bugs to be closed. Are you saying that's incorrect?
Others have also (correctly) said that you should not include, in a new
upload, changelog entries describing earlier releases. So in my
statement above, “already-released versions” is an important modifier.
> Cool, I'm glad to know this now. But where is it specified? A quick
> re-read of the changelog sections of the policy manual, developer's
> reference, and maintainer's guide didn't turn anything up. Did I miss
> it?
So now that we agree it's not too clear, and may be difficult to find, I
would welcome a bug report against Policy for clarifying this issue.
As someone who went looking for it recently when you didn't know the
recommendation: Where exactly would you expect to find this information,
which particular section of Policy and/or other guides?
--
\ “Are you pondering what I'm pondering?” “I think so, Brain, but |
`\ why would anyone want a depressed tongue?” —_Pinky and The |
_o__) Brain_ |
Ben Finney
Reply to: