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 __________________________________________________________________________ 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