[openstack-dev] [Oslo] Improving deprecated options identification and documentation
me at ronaldbradford.com
Wed Jan 20 18:34:07 UTC 2016
> > 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 ) and
> * the "follows_standard_deprecation" policy .
> 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
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.
>  Nova's current release notes based on "reno"; "Deprecation Notes":
>  OpenStack governance docs; tag "assert_follows_standard_deprecation":
> Regards, Markus Zoeller (markus_z)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev