openmw.org

Ok, so bzzt is complaining that changelog entries getting added in commits causes conflicts upon an attempt of revert which have to be solved (and he hates these with burning passion). So there's some motive to discuss the policy more. There are two solutions to this issue:
1. Either *every* single contributor needs to modify the changelog in a separate commit. This causes "commit bloat" as every PR that resolves a tracker issue now has a minimum of two commits, which isn't very nice - changelog modifying is not very meaningful in terms of git history and if for example the contributor pushes the commit that changes the changelog only after the first commit is pushed to git CIs will have to build the PR again. OCD triggered.
2. Or pre-0.45.0 policy is restored, where contributors keep their hands of the changelog file and only a maintainer/project leader updates the changelog manually upon the beginning of RC phase. The complaint is that this is more error-prone and makes recordkeeping more difficult (though it's proven the current approach isn't ideal in this area either). The benefit is that contributors or maintainers most likely don't need to solve merge conflicts at all due to changelog changes over time since the changelog doesn't change. Other thing is that the current GitLab tracker is somewhat less convenient than redmine for this because the roadmap table is no longer present and it's more difficult for the changelog updater to review the list of issues on the milestone.

Or of course everything can be left as is and bzzt and others with the same problem are kindly asked to resolve conflicts manually.

What do you think?

Would another solution be to use the gitlab wiki to host the changelog?

I've seen a couple of projects do changelogs by having a changelog folder, with small one-line markdown files for every change, that are then merged into a changelog file at release time.

Alternatively, maybe we could do something where PRs that add features are supposed to have a changelog entry in the first post (we'd probably want to set up a PR/MR template that makes it clear). The CI or person doing the merge or something like that could then automatically add the changelog entry. Alternatively, a person doing it by hand at release time could just look at every merge commit and see if it had a changelog entry.

This really seems like the kind of thing where there should be an automated tool that handles everything by magic by now.

First approach has an another drawback - if a developer wants to revert any commit, he needs to revert the commit with related changelog entry as well, but he can forget about it.

Why does removing changelog lines cause conflicts in the first place? Because it's single-spaced? Would having a double-spaced changelog make it stop conflicting?

It needs as many line breaks as you have context lines configured in git (I think three in either direction is the default). I'm also not sure how it copes when two commits add four lines (entry plus three line breaks) each in the same place as that might or might not automatically trigger a merge conflict even if there's no context overlap.