[Starlingx-discuss] [Doc] Release Notes Management

[Arce Moreno, Abraham]

Release Notes are ready to get incorporated into our StarlingX projects.
It is worth to spent some time reading the 15 minute Reno documentation [0].

[ Baseline ]

Release Notes Management baseline is ready for review [1]
        [Doc] Release Notes Management

Once this is approved it will be ported to the rest of our projects.

[ Demo ]

To generate our Release Note and Report a small amount of effort is required from both our
Developers and our Release team. Here you have a demo for Milestone branch m/2018.08 [2]
Includeing both efforts:
    [Doc] [Demo] Release Notes m/2018.08

[ Grouping ]

There is a convention to follow how Release Notes are grouped:
    - features
    - issues
    - upgrade
    - deprecations
    - critical
    - security
    - fixes
    - other

See [3] for an example.

[ Call to Action ]

In my limited understanding a typical flow would be as follows:

Developer [4]
1. Start common development workflow to create your change:
     "Hello My Change"
2. New! Create its release notes in reStructuredText, no major effort since title and content might
    be reused from git commit information:
     tox -e venv -- reno new hello-my-change
3. Submit your change for review.

Release Team 
1. Start development work to prepare the release, this might include git tag.
2. Create to generate the Reno Report
     tox -e releasenotes  
3. Submit your change for review.

In OpenStack it seems OpenStack Release Bot takes care of the Release Process. See Nova Release Notes [5]
for how it looks like.

[0] https://docs.openstack.org/reno/latest/
[1] https://review.openstack.org/#/c/590798/5
[2] https://review.openstack.org/#/c/591157/2
[3] https://review.openstack.org/#/c/591157/2/releasenotes/notes/milestone-branch-m201808-717218b5976a529e.yaml
[4] https://review.openstack.org/#/c/282520/
[5] https://docs.openstack.org/releasenotes/nova/rocky.html