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

Contributors

• C. Inspect the history of releases
• D. Write release notes

Proposed solution

Iteration 1: MVP (!153 (merged))

• 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.

Iteration 2

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.