Excerpts from Andreas Jaeger's message of 2015-11-09 10:11:33 +0100: > On 11/03/2015 08:46 PM, Doug Hellmann wrote: > > As we discussed at the summit, the release management team is > > modifying our change management tracking tools and processes this > > cycle. This email is the official announcement of those changes, > > with more detail than we provided at the summit. > > > > In past cycles, we have used a combination of Launchpad milestone > > pages and our wiki to track changes in releases. We used to pull > > together release notes for stable point releases at the time of > > release. Most of that work fell to the stable maintenance and release > > teams. Similarly, the release managers worked with PTLs and release > > liaisons at each milestone checkpoint to update Launchpad to > > accurately reflect the work completed at each stage of development. > > It's a lot of work to fix up Launchpad and assemble the notes and > > make sure they are accurate, which has caused us to be a bottleneck > > for clear and complete communication at the time of the release. > > We have been looking for ways to reduce that effort for these tasks > > and eliminate the bottleneck for some time. > > > > This cycle, to address these problems for our ever-growing set of > > projects, the release management team is introducing a new tool for > > handling release notes as files in-tree, to allow us to simply and > > continuously build the release notes for stable branch point releases > > and milestones on the master branch. The idea is to use small YAML > > files, usually one per note or patch, to avoid merge conflicts on > > backports and then to compile those files in a deterministic way > > into a more readable document for readers. Files containing release > > notes can be including in patches directly, or you can create a > > separate patch with release notes if you want to document a feature > > than spans several patches. The tool is called Reno, and it currently > > supports ReStructuredText and Sphinx for converting note input files > > to HTML for publication. Reno is git branch-aware, so we can have > > separate release notes documents for each release series published > > together from the master build. > > > > The documentation for Reno, including design principles and basic > > usage instructions, is available at [1]. For now we are focusing > > on Sphinx integration so that release notes are published online. > > We will add setuptools integration in a future version of Reno so > > that the release notes can be built with the source distribution. > > > > As part of this rollout, I will also be updating the settings for > > the gerrit hook script so that when a patch with "Closes-Bug" in > > the commit message is merged the bug will be marked as "Fix Released" > > instead of "Fix Committeed" (since "Fix Committed" is not a closed > > state). When that work is done, I'll send another email to let PTLs > > know they can go through their existing bugs and change their status. > > > > We are ready to start rolling out Reno for use with Liberty stable > > branch releases and in master for the Mitaka release. We need the > > release liaisons to create and merge a few patches for each project > > between now and the Mitaka-1 milestone. > > > > 1. We need one patch to the master branch of the project to add the > > instructions for publishing the notes as part of the project > > sphinx documentation build. An example patch for Glance is in > > [2]. > > > > 2. We need another patch to the stable/liberty branch of the project > > to set up Reno and introduce the first release note for that > > series. An example patch for Glance is in [3]. > > > > 3. Each project needs to turn on the relevant jobs in project-config. > > An example patch using Glance is in [4]. New patches will need > > to be based on the change that adds the necessary template [5], > > until that lands. > > Currently the job runs on *all* branches. I've proposed > https://review.openstack.org/242975 to run it only on Liberty and > master. Rereading your comments above, it might be that we only need to > run it on master, is that correct?
Yes, thanks for spotting this, we only need it on master. > > Note that currently glance is failing since the job runs on Liberty but > your change is not backported: https://review.openstack.org/238358 > > Andreas > > > 4. Reno was not ready before the summit, so we started by using the > > wiki for release notes for the initial Liberty releases. We also > > need liaisons to convert those notes to reno YAML files in the > > stable/liberty branch of each project. > > > > Please use the topic "add-reno" for all patches so we can track > > adoption. > > > > Once those merge, project teams can stop using Launchpad for tracking > > completed work. We will still use Launchpad for bug reports, for > > now. If a team wants to continue using it for tracking blueprints, > > that's fine. If a team wants to use Launchpad for scheduling work > > to be done in the future, but not for release tracking, that is > > also fine. The release management team will no longer be reviewing > > or updating Launchpad as part of the release process. > > > > Thanks, > > Doug > > > > [1] http://docs.openstack.org/developer/reno/ > > [2] https://review.openstack.org/241323 > > [3] https://review.openstack.org/241322 > > [4] https://review.openstack.org/241344 > > [5] https://review.openstack.org/241343 > > > > __________________________________________________________________________ > > 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 > > > __________________________________________________________________________ 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
