Open Stack

Em 04.11.2015 17:19, Jim Rollenhagen escreveu:
> On Wed, Nov 04, 2015 at 02:55:49PM -0500, Sean Dague wrote:
> On 11/04/2015 02:42 PM, Jim Rollenhagen wrote:
> > 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.
> 
> The AND version of this seems to respect the spirit of the original
> intent. The 3 month window was designed to push back a little on last
> minute deprecations for release, that we deleted the second master
> landed. Which looked very different for stable release vs. CD consuming
> folks.
> 
> The intermediate release or no-release model just wasn't considered
> initially.
> 
> Yeah, no worries there. So you're good with unreleased changes just
> being 3 months, no cycle boundaries? If so, I'll push up a change to 
> the
> governance repo for that.
> 
> // jim

It sounds reasonable to me. +1.