Open Stack

Hi Doug,

Thanks for posting this. I'm working on this for Zaqar now and there is 
a question. As for the stable/liberty patch, where does the 
"60fdcaba00e30d02" in [1] come from? Thanks.

[1] 
https://review.openstack.org/#/c/241322/1/releasenotes/notes/60fdcaba00e30d02-start-using-reno.yaml

On 04/11/15 08:46, 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.
>
> 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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--------------------------------------------------------------------------