Feature #8689

Consider building the changelog from changes files provided by the merged branches

Added by intrigeri 2015-01-13 16:55:57 . Updated 2019-10-22 06:44:47 .

Status:
Confirmed
Priority:
Elevated
Assignee:
Category:
Target version:
Start date:
2015-01-13
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

… 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:


Subtasks


History

#1 Updated by sajolida 2015-02-28 14:33:57

If we go this way, then the section “Documentation is not optional” should be adapted to make explain the additional requirements.

#2 Updated by sajolida 2015-08-14 11:44:00

  • Assignee set to bertagaz

#3 Updated by sajolida 2015-09-07 10:42:28

  • Target version changed from Sustainability_M1 to 2016

#4 Updated by anonym 2016-01-11 14:31:40

If implemented, for bugfixes we should mandate that the changelog entry includes “bugfix on $version_that_introduced_the_bug” when relevant.

#5 Updated by intrigeri 2016-01-16 11:50:54

https://github.com/openstack/reno provides a workflow and tools to handle that.

#6 Updated by Dr_Whax 2016-08-20 13:05:40

  • Assignee deleted (bertagaz)
  • Priority changed from Normal to Elevated
  • Target version deleted (2016)

#7 Updated by intrigeri 2016-12-08 12:30:58

  • Description updated

#8 Updated by intrigeri 2019-09-01 13:30:16

  • Category deleted (Continuous Integration)

#9 Updated by intrigeri 2019-10-22 06:44:47

  • Description updated