Open Stack

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.

	-Sean

-- 
Sean Dague
http://dague.net