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