Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>