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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
