Consider building the changelog from changes files provided by the merged branches
Originally created by @intrigeri on #8689 (Redmine)
… just like they do it for Tor. This would make the release process shorter by pushing to branch submitters the responsibility to write good changelog entries. It would also be needed to go further on the continuous integration path (releasing stuff automatically).
If we go this way, we could even request two different pieces of text:
- a changelog snippet
- a release notes snippet, if the changes warrant being mentioned there
=> our doc writers could review and improve the release notes incrementally during a dev cycle, instead of doing it in one go at release time (which is a blocking synchronization point right now).
The relationship between this and the process of writing the release notes was discussed on https://mailman.boum.org/pipermail/tails-project/2015-February/000118.html. One should re-read this discussion before starting work on this ticket, but IIRC the summary is that the release notes draft, once automatically assembled from the snippets at RC time, can be published on a blueprint that anyone can help improve (even if they’re not at ease with Git).
Prior art
We’re not the first ones to have this kind of problems and consider this sort of solutions:
- Tor ← XXX: pointers?
- Reno, used by OpenStack
- how GitLab does it: