Re: [openstack-dev] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

On 3/2/17, 4:42 PM, "Doug Hellmann"  wrote:

Excerpts from Alexandra Settle's message of 2017-03-02 16:25:46 +:
> 
> 
> On 3/2/17, 4:08 PM, "Doug Hellmann"  wrote:
> 
> Excerpts from Alexandra Settle's message of 2017-03-02 14:29:07 +:
> > 
> > 
> > From: Anne Gentle 
> > Date: Thursday, March 2, 2017 at 2:16 PM
> > To: Alexandra Settle 
> > Cc: "OpenStack Development Mailing List (not for usage questions)" 
, "openstack-d...@lists.openstack.org" 

> > Subject: Re: [OpenStack-docs] [docs][release][ptl] Adding docs to 
the release schedule
> > 
> > 
> > 
> > On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle 
> wrote:
> > Hi everyone,
> > 
> > I would like to propose that we introduce a “Review documentation” 
period on the release schedule.
> > 
> > We would formulate it as a deadline, so that it fits in the 
schedule and making it coincide with the RC1 deadline.
> > 
> > For projects that are not following the milestones, we would 
translate this new inclusion literally, so if you would like your project to be 
documented at docs.o.o, then doc must be introduced and reviewed one month 
before the branch is cut.
> > 
> > I like this idea, and it can align certain docs with string freeze 
logically.
> > 
> > I think the docs that are governed with this set of rules should be 
scoped only to those that are synched with a release, namely the Configuration 
Reference, Networking Guide, and Install Guides. [1]
> > 
> > For reference, those are the guides that would best align with 
"common cycle with development milestones." [2]
> > 
> > Scope this proposal to the released guides, clarify which repo 
those will be in, who can review and merge, and precisely when the cutoff is, 
and you're onto something here. Plus, I can hear the translation teams 
cheering. :)
> > 
> > 
> > I completely agree with everything here :) my only question is, 
what do you mean by “clarify which repo those will be in”? I had no intention 
of moving documentation with this suggestion Install guides either in 
openstack-manuals or their own $project repos :)
> > 
> > Next question – since there doesn’t appear to be a huge ‘no don’t 
do the thing’ coming from the dev list at this point, how and where do we 
include this new release information? Here? 
https://docs.openstack.org/project-team-guide/release-management.html#release-1
> > 
> > Anne
> > 
> > 
> > 1. 
https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation
> > 
> > 2. 
https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones
> > 
> > 
> > In the last week since we released Ocata, it has become 
increasingly apparent that the documentation was not updated from the 
development side. We were not aware of a lot of new enhancements, features, or 
major bug fixes for certain projects. This means we have released with 
incorrect/out-of-date documentation. This is not only an unfortunately bad 
reflection on our team, but on the project teams themselves.
> > 
> > The new inclusion to the schedule may seem unnecessary, but a lot 
of people rely on this and the PTL drives milestones from this schedule.
> > 
> > From our side, I endeavor to ensure our release managers are 
working harder to ping and remind doc liaisons and PTLs to ensure the 
documentation is appropriately updated and working to ensure this does not 
happen in the future.
> > 
> > Thanks,
> > 
> > Alex
> > 
> 
> As Thierry pointed out, we do need to consider the fact that more
> projects are using the cycle-with-intermediary process, so although
> we might tie dates to milestones we need to be careful that projects
> not tagging milestones are still covered in any processes.
> 
> Based on a similar discussion we had with the i18n team at the PTG,
> I think a good first step here is to document the agreement by
> writing a governance tag with a name like doc:managed. The tag
> description is the place to write down the answers to the questions
> from this thread.
> 
> For example, it would list the manuals that are in scope, what
> portion of the work the docs team will take on (initial writing?
> reviews?), and what portion of the work the project team needs 

Re: [openstack-dev] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Doug Hellmann]

Excerpts from Alexandra Settle's message of 2017-03-02 16:25:46 +:
> 
> 
> On 3/2/17, 4:08 PM, "Doug Hellmann"  wrote:
> 
> Excerpts from Alexandra Settle's message of 2017-03-02 14:29:07 +:
> > 
> > 
> > From: Anne Gentle 
> > Date: Thursday, March 2, 2017 at 2:16 PM
> > To: Alexandra Settle 
> > Cc: "OpenStack Development Mailing List (not for usage questions)" 
> , "openstack-d...@lists.openstack.org" 
> 
> > Subject: Re: [OpenStack-docs] [docs][release][ptl] Adding docs to the 
> release schedule
> > 
> > 
> > 
> > On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle 
> > wrote:
> > Hi everyone,
> > 
> > I would like to propose that we introduce a “Review documentation” 
> period on the release schedule.
> > 
> > We would formulate it as a deadline, so that it fits in the schedule 
> and making it coincide with the RC1 deadline.
> > 
> > For projects that are not following the milestones, we would translate 
> this new inclusion literally, so if you would like your project to be 
> documented at docs.o.o, then doc must be introduced and reviewed one month 
> before the branch is cut.
> > 
> > I like this idea, and it can align certain docs with string freeze 
> logically.
> > 
> > I think the docs that are governed with this set of rules should be 
> scoped only to those that are synched with a release, namely the 
> Configuration Reference, Networking Guide, and Install Guides. [1]
> > 
> > For reference, those are the guides that would best align with "common 
> cycle with development milestones." [2]
> > 
> > Scope this proposal to the released guides, clarify which repo those 
> will be in, who can review and merge, and precisely when the cutoff is, and 
> you're onto something here. Plus, I can hear the translation teams cheering. 
> :)
> > 
> > 
> > I completely agree with everything here :) my only question is, what do 
> you mean by “clarify which repo those will be in”? I had no intention of 
> moving documentation with this suggestion Install guides either in 
> openstack-manuals or their own $project repos :)
> > 
> > Next question – since there doesn’t appear to be a huge ‘no don’t do 
> the thing’ coming from the dev list at this point, how and where do we 
> include this new release information? Here? 
> https://docs.openstack.org/project-team-guide/release-management.html#release-1
> > 
> > Anne
> > 
> > 
> > 1. 
> https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation
> > 
> > 2. 
> https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones
> > 
> > 
> > In the last week since we released Ocata, it has become increasingly 
> apparent that the documentation was not updated from the development side. We 
> were not aware of a lot of new enhancements, features, or major bug fixes for 
> certain projects. This means we have released with incorrect/out-of-date 
> documentation. This is not only an unfortunately bad reflection on our team, 
> but on the project teams themselves.
> > 
> > The new inclusion to the schedule may seem unnecessary, but a lot of 
> people rely on this and the PTL drives milestones from this schedule.
> > 
> > From our side, I endeavor to ensure our release managers are working 
> harder to ping and remind doc liaisons and PTLs to ensure the documentation 
> is appropriately updated and working to ensure this does not happen in the 
> future.
> > 
> > Thanks,
> > 
> > Alex
> > 
> 
> As Thierry pointed out, we do need to consider the fact that more
> projects are using the cycle-with-intermediary process, so although
> we might tie dates to milestones we need to be careful that projects
> not tagging milestones are still covered in any processes.
> 
> Based on a similar discussion we had with the i18n team at the PTG,
> I think a good first step here is to document the agreement by
> writing a governance tag with a name like doc:managed. The tag
> description is the place to write down the answers to the questions
> from this thread.
> 
> For example, it would list the manuals that are in scope, what
> portion of the work the docs team will take on (initial writing?
> reviews?), and what portion of the work the project team needs to
> provide (contributing updates when major related happen in the code,
> having a liaison, and a "checkup" at a date specified near the end
> of the cycle). If there are any constraints about which projects
> can apply, those should be documented, too. Maybe 

Re: [openstack-dev] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

On 3/2/17, 4:08 PM, "Doug Hellmann"  wrote:

Excerpts from Alexandra Settle's message of 2017-03-02 14:29:07 +:
> 
> 
> From: Anne Gentle 
> Date: Thursday, March 2, 2017 at 2:16 PM
> To: Alexandra Settle 
> Cc: "OpenStack Development Mailing List (not for usage questions)" 
, "openstack-d...@lists.openstack.org" 

> Subject: Re: [OpenStack-docs] [docs][release][ptl] Adding docs to the 
release schedule
> 
> 
> 
> On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle 
> wrote:
> Hi everyone,
> 
> I would like to propose that we introduce a “Review documentation” period 
on the release schedule.
> 
> We would formulate it as a deadline, so that it fits in the schedule and 
making it coincide with the RC1 deadline.
> 
> For projects that are not following the milestones, we would translate 
this new inclusion literally, so if you would like your project to be 
documented at docs.o.o, then doc must be introduced and reviewed one month 
before the branch is cut.
> 
> I like this idea, and it can align certain docs with string freeze 
logically.
> 
> I think the docs that are governed with this set of rules should be 
scoped only to those that are synched with a release, namely the Configuration 
Reference, Networking Guide, and Install Guides. [1]
> 
> For reference, those are the guides that would best align with "common 
cycle with development milestones." [2]
> 
> Scope this proposal to the released guides, clarify which repo those will 
be in, who can review and merge, and precisely when the cutoff is, and you're 
onto something here. Plus, I can hear the translation teams cheering. :)
> 
> 
> I completely agree with everything here :) my only question is, what do 
you mean by “clarify which repo those will be in”? I had no intention of moving 
documentation with this suggestion Install guides either in openstack-manuals 
or their own $project repos :)
> 
> Next question – since there doesn’t appear to be a huge ‘no don’t do the 
thing’ coming from the dev list at this point, how and where do we include this 
new release information? Here? 
https://docs.openstack.org/project-team-guide/release-management.html#release-1
> 
> Anne
> 
> 
> 1. 
https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation
> 
> 2. 
https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones
> 
> 
> In the last week since we released Ocata, it has become increasingly 
apparent that the documentation was not updated from the development side. We 
were not aware of a lot of new enhancements, features, or major bug fixes for 
certain projects. This means we have released with incorrect/out-of-date 
documentation. This is not only an unfortunately bad reflection on our team, 
but on the project teams themselves.
> 
> The new inclusion to the schedule may seem unnecessary, but a lot of 
people rely on this and the PTL drives milestones from this schedule.
> 
> From our side, I endeavor to ensure our release managers are working 
harder to ping and remind doc liaisons and PTLs to ensure the documentation is 
appropriately updated and working to ensure this does not happen in the future.
> 
> Thanks,
> 
> Alex
> 

As Thierry pointed out, we do need to consider the fact that more
projects are using the cycle-with-intermediary process, so although
we might tie dates to milestones we need to be careful that projects
not tagging milestones are still covered in any processes.

Based on a similar discussion we had with the i18n team at the PTG,
I think a good first step here is to document the agreement by
writing a governance tag with a name like doc:managed. The tag
description is the place to write down the answers to the questions
from this thread.

For example, it would list the manuals that are in scope, what
portion of the work the docs team will take on (initial writing?
reviews?), and what portion of the work the project team needs to
provide (contributing updates when major related happen in the code,
having a liaison, and a "checkup" at a date specified near the end
of the cycle). If there are any constraints about which projects
can apply, those should be documented, too. Maybe "independent"
projects (not following the release cycle) are not candidates, for
example.

The tag application process section should cover who can propose a
tag, and who needs to approve it. In this case, I would think the
project team PTL and docs PTL should both agree, 

Re: [openstack-dev] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Doug Hellmann]

Excerpts from Alexandra Settle's message of 2017-03-02 14:29:07 +:
> 
> 
> From: Anne Gentle 
> Date: Thursday, March 2, 2017 at 2:16 PM
> To: Alexandra Settle 
> Cc: "OpenStack Development Mailing List (not for usage questions)" 
> , "openstack-d...@lists.openstack.org" 
> 
> Subject: Re: [OpenStack-docs] [docs][release][ptl] Adding docs to the release 
> schedule
> 
> 
> 
> On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle 
> > wrote:
> Hi everyone,
> 
> I would like to propose that we introduce a “Review documentation” period on 
> the release schedule.
> 
> We would formulate it as a deadline, so that it fits in the schedule and 
> making it coincide with the RC1 deadline.
> 
> For projects that are not following the milestones, we would translate this 
> new inclusion literally, so if you would like your project to be documented 
> at docs.o.o, then doc must be introduced and reviewed one month before the 
> branch is cut.
> 
> I like this idea, and it can align certain docs with string freeze logically.
> 
> I think the docs that are governed with this set of rules should be scoped 
> only to those that are synched with a release, namely the Configuration 
> Reference, Networking Guide, and Install Guides. [1]
> 
> For reference, those are the guides that would best align with "common cycle 
> with development milestones." [2]
> 
> Scope this proposal to the released guides, clarify which repo those will be 
> in, who can review and merge, and precisely when the cutoff is, and you're 
> onto something here. Plus, I can hear the translation teams cheering. :)
> 
> 
> I completely agree with everything here :) my only question is, what do you 
> mean by “clarify which repo those will be in”? I had no intention of moving 
> documentation with this suggestion Install guides either in openstack-manuals 
> or their own $project repos :)
> 
> Next question – since there doesn’t appear to be a huge ‘no don’t do the 
> thing’ coming from the dev list at this point, how and where do we include 
> this new release information? Here? 
> https://docs.openstack.org/project-team-guide/release-management.html#release-1
> 
> Anne
> 
> 
> 1. 
> https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation
> 
> 2. 
> https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones
> 
> 
> In the last week since we released Ocata, it has become increasingly apparent 
> that the documentation was not updated from the development side. We were not 
> aware of a lot of new enhancements, features, or major bug fixes for certain 
> projects. This means we have released with incorrect/out-of-date 
> documentation. This is not only an unfortunately bad reflection on our team, 
> but on the project teams themselves.
> 
> The new inclusion to the schedule may seem unnecessary, but a lot of people 
> rely on this and the PTL drives milestones from this schedule.
> 
> From our side, I endeavor to ensure our release managers are working harder 
> to ping and remind doc liaisons and PTLs to ensure the documentation is 
> appropriately updated and working to ensure this does not happen in the 
> future.
> 
> Thanks,
> 
> Alex
> 

As Thierry pointed out, we do need to consider the fact that more
projects are using the cycle-with-intermediary process, so although
we might tie dates to milestones we need to be careful that projects
not tagging milestones are still covered in any processes.

Based on a similar discussion we had with the i18n team at the PTG,
I think a good first step here is to document the agreement by
writing a governance tag with a name like doc:managed. The tag
description is the place to write down the answers to the questions
from this thread.

For example, it would list the manuals that are in scope, what
portion of the work the docs team will take on (initial writing?
reviews?), and what portion of the work the project team needs to
provide (contributing updates when major related happen in the code,
having a liaison, and a "checkup" at a date specified near the end
of the cycle). If there are any constraints about which projects
can apply, those should be documented, too. Maybe "independent"
projects (not following the release cycle) are not candidates, for
example.

The tag application process section should cover who can propose a
tag, and who needs to approve it. In this case, I would think the
project team PTL and docs PTL should both agree, after having the
conversation to ensure there is full understanding about the
expectations. It sounds a bit formal, but it shouldn't be a long
conversation in most cases and the structured process will help
reduce miscommunication.

After the tag is documented, the release team can add any dates to
the schedule 

Re: [openstack-dev] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

From: Anne Gentle 
Date: Thursday, March 2, 2017 at 2:16 PM
To: Alexandra Settle 
Cc: "OpenStack Development Mailing List (not for usage questions)" 
, "openstack-d...@lists.openstack.org" 

Subject: Re: [OpenStack-docs] [docs][release][ptl] Adding docs to the release 
schedule



On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle 
> wrote:
Hi everyone,

I would like to propose that we introduce a “Review documentation” period on 
the release schedule.

We would formulate it as a deadline, so that it fits in the schedule and making 
it coincide with the RC1 deadline.

For projects that are not following the milestones, we would translate this new 
inclusion literally, so if you would like your project to be documented at 
docs.o.o, then doc must be introduced and reviewed one month before the branch 
is cut.

I like this idea, and it can align certain docs with string freeze logically.

I think the docs that are governed with this set of rules should be scoped only 
to those that are synched with a release, namely the Configuration Reference, 
Networking Guide, and Install Guides. [1]

For reference, those are the guides that would best align with "common cycle 
with development milestones." [2]

Scope this proposal to the released guides, clarify which repo those will be 
in, who can review and merge, and precisely when the cutoff is, and you're onto 
something here. Plus, I can hear the translation teams cheering. :)


I completely agree with everything here :) my only question is, what do you 
mean by “clarify which repo those will be in”? I had no intention of moving 
documentation with this suggestion Install guides either in openstack-manuals 
or their own $project repos :)

Next question – since there doesn’t appear to be a huge ‘no don’t do the thing’ 
coming from the dev list at this point, how and where do we include this new 
release information? Here? 
https://docs.openstack.org/project-team-guide/release-management.html#release-1

Anne


1. 
https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation

2. 
https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones


In the last week since we released Ocata, it has become increasingly apparent 
that the documentation was not updated from the development side. We were not 
aware of a lot of new enhancements, features, or major bug fixes for certain 
projects. This means we have released with incorrect/out-of-date documentation. 
This is not only an unfortunately bad reflection on our team, but on the 
project teams themselves.

The new inclusion to the schedule may seem unnecessary, but a lot of people 
rely on this and the PTL drives milestones from this schedule.

From our side, I endeavor to ensure our release managers are working harder to 
ping and remind doc liaisons and PTLs to ensure the documentation is 
appropriately updated and working to ensure this does not happen in the future.

Thanks,

Alex


___
OpenStack-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



--

Read my blog: justwrite.click
Subscribe to Docs|Code: docslikecode.com
__
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] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Anne Gentle]

On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle 
wrote:

> Hi everyone,
>
>
>
> I would like to propose that we introduce a “Review documentation” period
> on the release schedule.
>
>
>
> We would formulate it as a deadline, so that it fits in the schedule and
> making it coincide with the RC1 deadline.
>
>
>
> For projects that are not following the milestones, we would translate
> this new inclusion literally, so if you would like your project to be
> documented at docs.o.o, then doc must be introduced and reviewed one month
> before the branch is cut.
>

I like this idea, and it can align certain docs with string freeze
logically.

I think the docs that are governed with this set of rules should be scoped
only to those that are synched with a release, namely the Configuration
Reference, Networking Guide, and Install Guides. [1]

For reference, those are the guides that would best align with "common
cycle with development milestones." [2]

Scope this proposal to the released guides, clarify which repo those will
be in, who can review and merge, and precisely when the cutoff is, and
you're onto something here. Plus, I can hear the translation teams
cheering. :)

Anne


1.
https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation

2.
https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones


>
> In the last week since we released Ocata, it has become increasingly
> apparent that the documentation was not updated from the development side.
> We were not aware of a lot of new enhancements, features, or major bug
> fixes for certain projects. This means we have released with
> incorrect/out-of-date documentation. This is not only an unfortunately bad
> reflection on our team, but on the project teams themselves.
>
>
>
> The new inclusion to the schedule may seem unnecessary, but a lot of
> people rely on this and the PTL drives milestones from this schedule.
>
>
>
> From our side, I endeavor to ensure our release managers are working
> harder to ping and remind doc liaisons and PTLs to ensure the documentation
> is appropriately updated and working to ensure this does not happen in the
> future.
>
>
>
> Thanks,
>
>
>
> Alex
>
>
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
>


-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.com
__
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] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

FYI, there's a few bugs for the Configuration Reference mentioning 
options for some services require updating. I've gone through the doc 
and created additional bugs and included the relevant PTL and docs liaison.


Thank you, Darren! I will review this morning :(

__
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] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Darren Chan]

On 2/3/17 5:07 am, Alexandra Settle wrote:


On 3/1/17, 5:58 PM, "John Dickinson"  wrote:

 
 
 On 1 Mar 2017, at 9:52, Alexandra Settle wrote:
 
 > Hi everyone,

 >
 > I would like to propose that we introduce a “Review documentation” 
period on the release schedule.
 >
 > We would formulate it as a deadline, so that it fits in the schedule and 
making it coincide with the RC1 deadline.
 >
 > For projects that are not following the milestones, we would translate 
this new inclusion literally, so if you would like your project to be documented 
at docs.o.o, then doc must be introduced and reviewed one month before the branch 
is cut.
 
 Which docs are these? There are several different sets of docs that are hosted on docs.o.o that are managed within a project repo. Are you saying those won't get pushed to

 docs.o.o if they are patched within a month of the cycle release?

The only sets of docs that are published on the docs.o.o site that are managed 
in project-specific repos is the project-specific installation guides. That 
management is entirely up to the team themselves, but I would like to push for 
the integration of a “documentation review” period to ensure that those teams 
are reviewing their docs in their own tree.

This is a preferential suggestion, not a demand. I cannot make you review your 
documentation at any given period.

The ‘month before’ that I refer to would be for introduction of documentation 
and a review period. I will not stop any documentation being pushed to the repo 
unless, of course, it is untested and breaks the installation process.
 
 
 >

 > In the last week since we released Ocata, it has become increasingly 
apparent that the documentation was not updated from the development side. We were 
not aware of a lot of new enhancements, features, or major bug fixes for certain 
projects. This means we have released with incorrect/out-of-date documentation. 
This is not only an unfortunately bad reflection on our team, but on the project 
teams themselves.
 >
FYI, there's a few bugs for the Configuration Reference mentioning 
options for some services require updating. I've gone through the doc 
and created additional bugs and included the relevant PTL and docs liaison.

 > The new inclusion to the schedule may seem unnecessary, but a lot of 
people rely on this and the PTL drives milestones from this schedule.
 >
 > From our side, I endeavor to ensure our release managers are working 
harder to ping and remind doc liaisons and PTLs to ensure the documentation is 
appropriately updated and working to ensure this does not happen in the future.
 >
 > Thanks,
 >
 > Alex
 
 
 > __

 > 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-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



__
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