Bug#784397: Workflow with latest changelog entry un-finalised

[Ben Finney]

Here's more on the motivation for this bug report:

On 11-May-2015, Barry Warsaw wrote:
> On May 06, 2015, at 11:38 AM, Ben Finney wrote:
> >This mode of working is supported in (at least) Emacs's
> >‘debian-changelog-mode’, so I was happy when I learned it years
> >ago.
> >
> >> I always have to manually write a fake entry just to do a local
> >> build. :(
> >
> >That's no good. I'll [report bug#784397 against ‘debchange’], it
> >should be able to handle this. It's normal with Emacs
> >‘debian-changelog-mode’ to have the changelog in this state before
> >release; ‘dch’ should be able to co-operate.

> > a complete signature line on the changelog entry indicates the
> > release is complete and ready to upload, and declares who released
> > it and when.
> 
> Really?  Doesn't UNRELEASED signal that well enough?

While the package is marked “UNRELEASED”, putting a completed release
signature *in the VCS* is an arbitrary untruth. Untruths don't belong
in the VCS, is my position.

> At least, I've never seen the empty signature line anywhere else. I
> don't think either is sufficient to say "hey, I am not ready to
> release this package yet, so please don't do it out from under me."

It's simply the avoidance of communicating “the release is done by
this specific person at this specific time”. The release *isn't* done,
by anyone at any time. So the information isn't there yet.

> I've done something like this in such cases:
> 
> http://anonscm.debian.org/viewvc/python-modules/packages/python-pip/trunk/debian/changelog?revision=32519&view=markup

Compared with that, my workflow seems quite streamlined!

> So, given a [VCS working tree], how do you go through the process of
> building a source package without getting tripped up by this
> problem?

* Changelog entry starts un-finalised (as created by Emacs
  ‘debian-changelog-mode’ with ‘C-c C-a’ to add an entry.)

* Until ready to release:

  * Hack hack hack.
    Write description in changelog.

  * In the Emacs buffer for ‘debian/changelog’, hit ‘C-c C-f’ to
    finalise it.
    Save the buffer.

    (I would expect ‘debchange --release’ to do the same thing,
    hence bug#784397.)

  * Start the build (‘git-buildpackage --git-export=WC’, etc.)
    to test the changes.

  * While waiting: in Emacs, ‘C-c C-e’ to re-open (un-finalise) the
    changelog entry.

  * If the build succeeds: commit to VCS.

  * Repeat.

* Only when all changes for release have been tested:

  * Make final non-functional edits to changelog entry.

  * In the Emacs buffer for ‘debian/changelog’, hit ‘C-c C-f’ to
    finalise it.
    Save the buffer.

  * Start the build of the finalised release.

  * The build succeeds (because no functional changes were added).
    Commit to VCS.

  * Upload the package.

So, the changelog is finalised temporarily every time I make a build
happen. Before the release, though, the finalised changelog entry is a
*lie*, a fiction for the purpose of testing the build. That lie
doesn't make it into VCS.

-- 
 \      “Probably the earliest flyswatters were nothing more than some |
  `\    sort of striking surface attached to the end of a long stick.” |
_o__)                                                     —Jack Handey |
Ben Finney <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20150512/a77f8aad/attachment.sig>