[openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

Sean McGinnis sean.mcginnis at gmx.com
Thu Aug 11 13:47:56 UTC 2016


> >>
> >> As follow up on the mailing list discussion [0], gerrit activity
> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
> >> discussion how Cinder follows, or rather does not follow, the standard
> >> deprecation policy [4] as the project has been tagged on the assert
> >> page [5].
> >>
<snip>
> >>
> >> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
> >> [1] https://review.openstack.org/#/c/348032/
> >> [2] https://review.openstack.org/#/c/348042/
> >> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
> >> [4] https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
> >> [5] https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
> >>
> >
> > Can you be more specific about what you mean? Are you saying that
> > the policy isn't being followed because the drivers were removed
> > without a deprecation period, or is there something else to it?
> >
> > Doug
> >
> 
> Yes, that's how I see it. Cinder's own policy is that the drivers can
> be removed without any warning to the consumers while the standard
> deprecation policy defines quite strict lines about informing the
> consumer of the functionality deprecation before it gets removed.
> 
> - Erno

It is a good point. I think it highlights a common thread though with
the other discussion that, at least so far, third party drivers are
treated differently than the rest of the code.

For any other functionality we certainly follow the deprecation policy.
Even in existing drivers we try to enforce that any driver renames,
config setting changes, and similar non-backwards compatible changes go
through the normal deprecation cycle before being removed.

Ideally I would love it if we could comply with the deprecation policy
with regards to driver removal. But the reality is, if we don't see that
a driver is being supported and maintained by its vendor, then that
burden can't fall on the wider OpenStack and Cinder community that has
no way of validating against physical hardware.

I think third party drivers need to be treated differently when it comes
to the deprecation policy. If that is not acceptable, then I suppose we
do need to remove that tag. Tag removal would be the lesser of the two
versus keeping around drivers that we know aren't really being
maintained.

If it came to that, I would also consider creating a new cinder-drivers
project under the Cinder umbrella and move all of the drivers not tested
by Jenkins over to that. That wouldn't be a trivial undertaking, so I
would try to avoid that if possible. But it would at least allow us to
still get code reviews and all of the benefits of being in tree. Just
some thoughts.

Sean

> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list