[openstack-dev] [release] new change management tools and processes for stable/liberty and mitaka

Doug Hellmann doug at doughellmann.com
Mon Nov 9 21:07:32 UTC 2015


Excerpts from Doug Hellmann's message of 2015-11-03 14:46:04 -0500:
> 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.
> 
> 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
> 

fungi and AJaeger identified a hole in the existing setup that might
allow bad changes on stable branches to break master. We're working on
fixing that right now. Most of the changes are in project-config or
reno, but we need release liaisons to do 2 more things within their
projects.

1. Add a file to the releasenotes documentation build that does not
   specify a branch. You might already have this, but if not you
   can copy what I have in https://review.openstack.org/#/c/243302
   for glance. This file will let us test building release notes from
   the "current" branch, which varies depending on where the patch is
   submitted.

2. Backport the reno configuration from  master to stable/liberty
   so we can run the releasenotes build in the check and gate queues
   for stable/liberty.

The combination of those two patches will let us test changes to reno
notes in stable branches before they merge, ensuring that the release
notes always build properly.

Both of the changes should go into master. Please keep using the
add-reno topic so we can track the changes.

Sorry for the extra work, and thanks to fungi and AJaeger for spotting
the hole and helping figure out how to plug it.

Doug



More information about the OpenStack-dev mailing list