Re: Merge request friendly handling of debian/changelog
Hi Bastian,
Full disclaimer: I probably don't contribute often enough inside
Debian to be a reference on it but thinking about it I'm wondering if
it wouldn't be easier to do it another way.
On Mon, Oct 21, 2019 at 8:06 PM Bastian Blank <waldi@debian.org> wrote:
> There is "gbp dch", which ignores merge commits (so no really good for
> merge requests), but I don't consider it to have enough control over the
> content of the changelog.
I honestly generally only use gbp dch (and I reformat sometimes its
output to make it prettier).
2 reasons for that:
* it avoids conflicts when you have several MR
* it also forces me to have more relevant commit messages. Most of the
time the changelog entry I've seen in the MR is the same as the commit
message anyway so gbp dch would generate the same output, you're just
doing extra work which is already automated inside gbp dch
On another point, it would be really nice if we could have a way to
squash merge requests to avoid having the merge commit every time
cluttering the git history. I know that github has it, which lets you
rework the final commit message if you feel like it's necessary and
that allows you, as a contributor to not have to squash and force push
after each feedback for example (that also adds the MR number
automatically which is nice). I'm pretty sure there's a way to do it
in gitlab I just haven't seen it available yet in salsa.
> The way that for example GitLab chooses in many locations is to create
> split files and merge them together in the final release process. They
> now not only use that for the core software changelog[1], but also for
> stuff like release posts.
It looks like the same idea as the reno software that openstack uses:
https://github.com/openstack/reno
But doesn't it clutter a bit your tree for things that you're going to
get in your changelog anyway in the end?
> So one rough idea could be:
> - "dch $message" writes a dummy entry to debian/changelog if it does not
> exist and the entry to debian/changelog-unreleased/$hash.
> - "dch --release" collects the snippets and creates one large entry.
Other though, could we instead not populate the changelog inside the
MR but have a script that takes a MR as input and merges the MR using
the title of the MR as short description and description of the MR as
long description? (yes it is kind of what a merge squash does on
github)
And then use gbp dch to take care of actually updating the changelog
when the release is actually ready?
Thanks,
Joseph
Reply to: