Build the changelog from GitLab MRs rather than from Git commits
Writing the changelog can be one of the most time-consuming and stressful part of the release process.
RMs have polled the community in the "[Tails-dev] Do you read the changelog?" discussion, to figure out whether it still made sense to have a detailed changelog at all, and if yes, what would be the minimal requirements for it.
Use cases for reading the changelog
Technical users or occasional contributors
- A Determine […] what impact the change might have to me in regards how I use Tails
- B. To learn and/or out of curiosity
- C. Inspect the history of releases
- D. Write release notes
Write a program that:
fetches from GitLab the list of issues and MRs closed by a specified set of releases, and presents them together, grouped by milestone, via 1 single user operation;
by default, for each MR, displays the corresponding commit messages.
The RM pastes the output of this program as-is in the changelog file.
Publish the information generated by iteration 1 over HTTPS somewhere (so one can click on links to go explore issues/MRs/commits further).
Impact on Tails work
The discussion mentioned above seems to tell us that this proposal would:
Make it cheaper to prepare a release
The technical writers may miss the rephrasing step currently done by the RM.
- Proposed mitigation: put efforts into "express clearly what we're doing and why" effort via issue/MR titles and commit messages, rather than on the RM-at-release-time's shoulders.
Give technical writers access to the info they need to write the release notes earlier in the release process
Increase the incentive to write good issue/MR titles and commit messages.