Release notes for future versions

[David Lawrence]

My proposal for discussion for an updated release notes process

1) When a bug is approved for inclusion in a release, the approver decides if a release note
is warranted and adds the relnote keyword to the keywords field of the bug (happens more or less now).

2) The approver also sets the target milestone appropriately so the release manager will know which
release notes should contain the summary.

3) Once we are ready for a development snapshot to be made for the next release, the release
manager looks for all bugs targeted for that release and has the relnote keyword set. Also  a top level release
notes bug is created for tracking and to also contain the high level key points for the release which will be
reviewed separately.

4) The release manager goes through the bug list and adds a brief summary of the bug fix to the "User Story"
field for each bug.

5) The release manager sets the relnote? flag for each with the approver as the requestee. Would someone else
be better for the requestee?

6) The requestee reviews the release note summary and sets the relnote+ flag or relnote- if something needs to be changed.

7) Once all release notes are reviewed, the release manager will use a script to pull the high level summaries, each of the
individual summaries per bug and using a template, create a new release notes page to be shipped with the final release.
The individual summaries can be separated by topic or component.

The goal of all of this is to figure out how to:

1) start this whole process as early as possible so that it can be revised  over time and be ready when release time comes around.

2) And to be able to script this so that the release process can systematically pull everything using a bug query and construct
the release notes page easily.

Thoughts?
dkl

On 01/21/2015 09:35 AM, Gervase Markham wrote:
> On 16/01/15 18:10, Frédéric Buclin wrote:
>> I disagree. This requires to compile the docs to read them.
> No, because there will be a copy on bugzilla.readthedocs.org.
>
>>> require the patch to contain a patch to the release notes if it's
>>> release-noteworthy. This means all the work is done at the time of patch
>>> submission.
>> I disagree here too. It's not the job of the contributor to decide what
>> should be relnoted and what shouldn't. 
> Well, the contributor in collaboration with their reviewer.
>
> Who adds the relnote keyword at the moment?
>
>> I made another proposal on IRC yesterday. The idea is to still add the
>> 'relnote' keyword as we always did, but we update release notes for each
>> development release instead of waiting for rc1. The bug list between two
>> consecutive dev releases is not that big. And we have a better idea of
>> what is important and what is pretty minor.
> I like that idea. :-) That may well help.
>
> Gerv
>
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dkl@mozilla.com>

-- 
David Lawrence
dkl at mozilla.com
bugzilla.mozilla.org