Open Stack

Em 04.11.2015 11:32, Jim Rollenhagen escreveu:
> On Wed, Nov 04, 2015 at 08:44:36AM -0500, Jay Pipes wrote:
> On 11/03/2015 11:40 PM, Gabriel Bezerra wrote:
> >Hi,
> >
> >The change in https://review.openstack.org/237122 touches a feature from
> >ironic that has not been released in any tag yet.
> >
> >At first, we from the team who has written the patch thought that, as it
> >has not been part of any release, we could do backwards incompatible
> >changes on that part of the code. As it turned out from discussing with
> >the community, ironic commits to keeping the master branch backwards
> >compatible and a deprecation process is needed in that case.
> >
> >That stated, the question at hand is: How long should this deprecation
> >process last?
> >
> >This spec specifies the deprecation policy we should follow:
> >https://github.com/openstack/governance/blob/master/reference/tags/assert_follows-standard-deprecation.rst
> >
> >
> >As from its excerpt below, the minimum obsolescence period must be
> >max(next_release, 3 months).
> >
> >"""
> >Based on that data, an obsolescence date will be set. At the very
> >minimum the feature (or API, or configuration option) should be marked
> >deprecated (and still be supported) in the next stable release branch,
> >and for at least three months linear time. For example, a feature
> >deprecated in November 2015 should still appear in the Mitaka release
> >and stable/mitaka stable branch and cannot be removed before the
> >beginning of the N development cycle in April 2016. A feature deprecated
> >in March 2016 should still appear in the Mitaka release and
> >stable/mitaka stable branch, and cannot be removed before June 2016.
> >"""
> >
> >This spec, however, only covers released and/or tagged code.
> >
> >tl;dr:
> >
> >How should we proceed regarding code/features/configs/APIs that have not
> >even been tagged yet?
> >
> >Isn't waiting for the next OpenStack release in this case too long?
> >Otherwise, we are going to have features/configs/APIs/etc. that are
> >deprecated from their very first tag/release.
> >
> >How about sticking to min(next_release, 3 months)? Or next_tag? Or 3
> >months? max(next_tag, 3 months)?
> 
> -1
> 
> The reason the wording is that way is because lots of people deploy
> OpenStack services in a continuous deployment model, from the master 
> source
> branches (sometimes minus X number of commits as these deployers run 
> the
> code through their test platforms).
> 
> Not everyone uses tagged releases, and OpenStack as a community has
> committed (pun intended) to serving these continuous deployment 
> scenarios.
> 
> Right, so I asked Gabriel to send this because it's an odd case, and 
> I'd
> like to clear up the governance doc on this, since it doesn't seem to
> say much about code that was never released.
> 
> The rule is a cycle boundary *and* at least 3 months. However, in this
> case, the code was never in a release at all, much less a stable
> release. So looking at the two types of deployers:
> 
> 1) CD from trunk: 3 months is fine, we do that, done.
> 
> 2) Deploying stable releases: if we only wait three months and not a
> cycle boundary, they'll never see it. If we do wait for a cycle
> boundary, we're pushing deprecated code to them for (seemingly to me) 
> no
> benefit.
> 
> So, it makes sense to me to not introduce the cycle boundary thing in
> this case. But there is value in keeping the rule simple, and if we 
> want
> this one to pass a cycle boundary to optimize for that, I'm okay with
> that too. :)
> 
> (Side note: there's actually a third type of deployer for Ironic; one
> that deploys intermediate releases. I think if we give them at least 
> one
> release and three months, they're okay, so the general standard
> deprecation rule covers them.)
> 
> // jim

So, summarizing that:

* untagged/master: 3 months

* tagged/intermediate release: max(next tag/intermediate release, 3 
months)

* stable release: max(next release, 3 months)

Is it correct?