On Wed, Nov 04, 2015 at 04:08:18PM -0300, Gabriel Bezerra wrote:
> 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?

No, my proposal is that, but s/max/AND/.

This also needs buyoff from other folks in the community, and an update
to the document in the governance repo which requires TC approval.

For now we must assume a cycle boundary and three months, and/or hold off on
the patch until this is decided.

// jim

__________________________________________________________________________
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

Reply via email to