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

[Doug Hellmann]

Excerpts from Lingxian Kong's message of 2015-11-09 15:00:25 +0800:
> On Wed, Nov 4, 2015 at 3:46 AM, Doug Hellmann  wrote:
> > 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].
> >
> 
> Hi, Doug,
> 
> I am gonna do this in Mistral project, but I wonder how
> releasenotes/source/conf.py is generated? since I found there are some
> contents specific to Glance.
> 

I used the sphinx-quickstart program to generate that file. You could
copy one from an existing patch and change the parts that are not
relevant to your project.

Doug

__
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

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

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2015-11-07 16:42:40 +0100:
> On 11/03/2015 08:46 PM, Doug Hellmann wrote:
> > [...]
> > 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].
>  > [...]
> 
> What shall we do with projects that do not have a stable/liberty? For 
> example openstack-doc-tools does not have one and we hope we don't need one?

There are 2 ways to handle projects without the stable branch. You
could simply write the notes in a single rst file and skip using
reno. The point of reno is to make backporting notes easier, but
if you aren't doing backports that's not necessary.

If you want to use reno, just set up a page that lists the releases
from the master branch.

> 
> Does the following look ok?
> https://review.openstack.org/242748

That's a good start. You could replace the contents of
releasenotes/source/index.rst with something like

  .. release-notes::
 :branch: origin/master

> 
> Also, what do you think of adding this to openstack-manuals? We do not 
> tag releases for the manuals but release continously. Will the tools 
> work fine here?

reno depends on the tags to know how to organize the notes. If you're
not tagging versions of the manuals, you won't get much benefit from it.
We should talk about alternative ways to build a good changelog for the
manuals, if you want to try to automate some of that.

Doug

> 
> Andreas

__
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

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

[Doug Hellmann]

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
> 

We've had a couple of projects ask about what to do for deliverables
spread across more than one repository. For now, it's only necessary to
add reno to one 

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

[Doug Hellmann]

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,
> 

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

[Doug Hellmann]

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. 

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

[Andreas Jaeger]

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?


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] 

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

[Lingxian Kong]

On Wed, Nov 4, 2015 at 3:46 AM, Doug Hellmann  wrote:
> 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].
>

Hi, Doug,

I am gonna do this in Mistral project, but I wonder how
releasenotes/source/conf.py is generated? since I found there are some
contents specific to Glance.


-- 
Regards!
---
Lingxian Kong

__
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

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

[Andreas Jaeger]

On 11/03/2015 08:46 PM, Doug Hellmann wrote:

[...]
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].

> [...]

What shall we do with projects that do not have a stable/liberty? For 
example openstack-doc-tools does not have one and we hope we don't need one?


Does the following look ok?
https://review.openstack.org/242748

Also, what do you think of adding this to openstack-manuals? We do not 
tag releases for the manuals but release continously. Will the tools 
work fine here?


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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

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

[Doug Hellmann]

Excerpts from Louis Taylor's message of 2015-11-04 08:05:44 +:
> On Wed, Nov 04, 2015 at 03:03:29PM +1300, Fei Long Wang wrote:
> > 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
> 
> This is from running the reno command to create a uniquely named release note
> file. See http://docs.openstack.org/developer/reno/usage.html

Right, we need the files to have a unique name so reno generates a part
of the file name as unique, combined with the partial filename you give
it on the command line.

Doug

__
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

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

[Louis Taylor]

On Wed, Nov 04, 2015 at 03:03:29PM +1300, Fei Long Wang wrote:
> 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

This is from running the reno command to create a uniquely named release note
file. See http://docs.openstack.org/developer/reno/usage.html

Cheers,
Louis


signature.asc
Description: PGP signature
__
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-dev] [release] new change management tools and processes for stable/liberty and mitaka

[Doug Hellmann]

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

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

[Fei Long Wang]

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