I think numbering in GitLab is a bit of a mess. GitLab uses #12345 for issues, !123 for merge requests etc. (Where as github uses #12345 for both). Anyway we are currently labeling commit summaries with the issue number when one exists or merge number otherwise. This is for our own reference, but also so that GitLab automatically cross references commits back to issues or merge requests in the GitLab web interface.

I was thinking that the reference numbers we used against each bug fix in the release notes should be an exact string match for what is, or could have been used, on the end of the commit message summary line. So like this:

Can you do the next release of GParted please. It's been long enough since the last release and there's enough change to justify it. This might well become the last GTK2 release. I want to get pending changes into the hands of the users before we merge the GTK3 port and start raising minimum requirements and dropping support for the oldest distros.

It's still early stages of the GTK3 port review, but it is looking promising. It might be ready for merge in a month. One thing I have though of is to complete review and merge in phases based on Luca's patch structuring. The first phase would be "modern-gtk2" which would raise the minimum version to gtkmm-2.24. Following phases would be "port-to-gtk3" and "modern-gtk3".

So far I add each change to a local copy of the NEWS file immediately after the change is committed. This isn't too hard to maintain because I also update posts like this in the forum as well.

Regarding point (1), including a NEWS entry with each patch set makes a single file the clash point for all patch sets. This makes for more work when committing changes because only one patch set will see the currently committed NEWS file. All other patch sets have to be altered to work with the updated NEWS file. Personally I find this to be extra work for little value.

Regarding point (2), this could be a great way to double-check to see if any committed changes are missed in the NEWS file. Currently I do something similar in an effort to ensure that I don't miss the names of any language translation contributors.

I know you were wondering about keeping a record of the fixes made to GParted for each release. As well as this record, here are a couple of alternative ideas for how we could work:

Add a NEWS file entry as part of producing a patch(set). For third party pull requests we can add one afterwards.

Query the git commit messages for the suffix summary lines we add. This is only going to work so long as we follow existing working practice of adding suffix lines. I missed the suffix summary lines for one merge request (Merge Request 2 - Remove support for obsolete devkit-disks automount inhibitor) when still learning how to work with pull requests in GitLab. Otherwise here is a simple command to list them: