Open Stack

Markus,



> > Yes, in what release it is to be removed, e.g. Mitaka.  So when is
> > that release cycle, i.e. now once removed there is no record.
>
> The information at which point in time a removal will happen can be
> derived from a combination of:
> * the "Deprecation Notes" (e.g. Nova's at [1]) and
> * the "follows_standard_deprecation" policy [2].
> I don't see the immediate need to duplicate that information.
>
>
The potential duplication you refer to enables code scanning/automation to
detect and even initiate steps at the start of a release cycle to remove
deprecated options.
Looking at documented notes is a more inconsistent manual approach. The
number of deprecated options should not be high, I do not see the issue in
ensuring this information is in code as well as docs.



> I agree that there should be an explanation in ``deprecation_reason``
> if ``deprecated_for_removal=True`` **why** we deprecated it and which
> follow up actions seem to be reasonable for the ops.
>
>
Thanks!  I think for now, stating a reason, stating what release it was
deprecated and what release it should be removed provides a starting point
with a low barrier of entry to see results.

Ronald (rbradfor)



> References:
> [1] Nova's current release notes based on "reno"; "Deprecation Notes":
>
>
> http://docs.openstack.org/releasenotes/nova/unreleased.html#deprecation-notes
> [2] OpenStack governance docs; tag "assert_follows_standard_deprecation":
>
>
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
>
> Regards, Markus Zoeller (markus_z)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160120/dcc97487/attachment-0001.html>