Open Stack

Kuvaja, Erno wrote:
> [...]
> We try to have python-glanceclient and glance_store including release notes upon the release time. We use in tree doc/source/index.rst for ease of access. This provides our release notes through: docs.openstack.org/developer/python-glanceclient/ and you can easily follow up stable branches via git: https://github.com/openstack/python-glanceclient/blob/stable/kilo/doc/source/index.rst
> 
> I've been trying to push mentality in to our community that last thing before release, we merge release notes update and tag that. What comes to stable, I think it's worth of adding release notes in the backport workflow.
> [...]
> It would be extremely great if we did not need to overcomplicate the workflow with the release notes. They are not nuclear science and lets not try to make it complicate enough to need a doctorate to understand how to a) add them b) correct/fix them c) troubleshoot the generation _when_ something breaks in that workflow.

The main issue with maintaining release notes as a document in tree is
that it requires a stable release manager to "produce" the release. One
of the goals of the change we are pushing here is to not require stable
release managers anymore, since nobody wants to do that job.

Robert's proposal solves the issue of merge conflicts, which allows to
distribute the role of curating release notes. It makes it a duty of the
backporter rather than a duty of the stable release manager. It also
lets us have best-effort intermediary release notes available for those
consuming between tagged commits.

However I agree that with the "tag now and then" approach we are
dangerously close to requiring stable release managers again (if only to
make the conscious choice to release). And if we do, directly curating a
release notes doc in the tree is simpler than relying on a directory
structure to produce them.

So I guess we are left with a choice:

- abandon the idea of not requiring stable branch release managers,
require "stable branch liaisons" in each project to tag stable branch
releases for their project from time to time, and ask them to curate a
"release notes" document in the tree before they do so

- use Robert's system to continuously produce release notes, and have
lightweight triggers for tags from time to time (after a CVE fix, at
someone's request, after a number of commits without a release, after a
period of time without a release) that do not formally require a "stable
release manager" or put additional stress on existing stable branch
liaisons.

I think I prefer the second option, because it has potential for
providing a better experience for people consuming stable branches
between tagged releases.

-- 
Thierry Carrez (ttx)