Changelog policy again

Everything about development and the OpenMW source code.
Post Reply
User avatar
Capostrophic
Posts: 662
Joined: 22 Feb 2016, 20:32

Changelog policy again

Post by Capostrophic » 23 Feb 2019, 21:40

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?

User avatar
psi29a
Posts: 4644
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Changelog policy again

Post by psi29a » 23 Feb 2019, 23:48

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

User avatar
Ace (SWE)
Posts: 829
Joined: 15 Aug 2011, 14:56

Re: Changelog policy again

Post by Ace (SWE) » 24 Feb 2019, 00:44

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.

User avatar
AnyOldName3
Posts: 1565
Joined: 26 Nov 2015, 03:25

Re: Changelog policy again

Post by AnyOldName3 » 24 Feb 2019, 01:52

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.
AnyOldName3, Master of Shadows

User avatar
akortunov
Posts: 621
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Changelog policy again

Post by akortunov » 24 Feb 2019, 05:47

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.

User avatar
wareya
Posts: 338
Joined: 09 May 2015, 13:07

Re: Changelog policy again

Post by wareya » 24 Feb 2019, 06:15

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?
paying attention to #1751 #2473 #3609 #3862/#3929 #3807 #4297 #4623

User avatar
AnyOldName3
Posts: 1565
Joined: 26 Nov 2015, 03:25

Re: Changelog policy again

Post by AnyOldName3 » 25 Feb 2019, 18:50

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.
AnyOldName3, Master of Shadows

Post Reply