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) > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
