Open Stack

Excerpts from Emilien Macchi's message of 2017-10-13 15:02:10 -0700:
> Greeting folks,
> 
> I hope we can get attention from stable-maint, release-managers and
> installers projects.
> 
> 
> ## Background
> 
> Some projects tried hard to follow stable policy but it didn't finish
> well: https://review.openstack.org/#/c/507924/
> This policy is too strict for projects like installers, although it's
> not a reason why the projects wouldn't be "stable".
> We decided to discuss again about the tag and how it works for installers.
> 
> ## Proposal
> 
> Proposal 1: create a new policy that fits for projects like installers.
> I kicked-off something here: https://review.openstack.org/#/c/511968/
> (open for feedback).
> Content can be read here:
> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
> Tag created here: https://review.openstack.org/#/c/511969/ (same,
> please review).
> 
> The idea is really to not touch the current stable policy and create a
> new one, more "relax" that suits well for projects like installers.
> 
> Proposal 2: change the current policy and be more relax for projects
> like installers.
> I haven't worked on this proposal while it was something I was
> considering doing first, because I realized it could bring confusion
> in which projects actually follow the real stable policy and the ones
> who have exceptions.
> That's why I thought having a dedicated tag would help to separate them.
> 
> Proposal 3: no change anywhere, projects like installer can't claim
> stability etiquette (not my best option in my opinion).
> 
> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
> this need), please get involved in the review process.
> 
> Thanks,

It seems appropriate for new versions of deployment tools to be
extended past the point where other types of projects allow feature
additions to add support for new hardware or operating systems to
old releases.

Option 1 seems like the most straightforward approach, because it
doesn't change the definition of the existing tag and cause confusion
about which definition applies to a given version of a given project.

Doug