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 <wa...@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
