<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> * When an option is changed, or marked as deprecated, during normal reviews<br>
> it should then be identified accordingly with these new attributes.<br>
> * The "changed" attribute would only be applicable moving forward with a<br>
> developer change in default value, ranges etc (changing help text or<br>
> re-ordering is not a change).<br>
<br>
</span>Would "changed" hold a list of changes, to provide a history? Or would<br>
it just describe the difference since the last release?<br>
<span class=""><br></span></blockquote><div><br></div><div>I would consider "changed" as last release the option has changed, so that effectively for a given current release did the option change in that release, or not.  An option could change in multiple releases, and would be indicated as such during each release cycle.</div><div><br></div><div><div style="font-size:12.8px">I do not see this feature providing specifics such as "Option X changed default value from False to True".  It would be that in a section "Changed Options" there is a list of options marked as changed. The use of comparing generated configuration files between releases as used now would determine specifics.  The goal here is to narrow down the time to do the work across many projects and projects with many options.  <br></div><div style="font-size:12.8px"><br></div></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> * Any new options get the "released" attribute.<br>
<br>
</span>And that would be set to the version in which the new attribute was<br>
added? Maybe "added_in" is a better name?<br>
<span class=""><br></span></blockquote><div>Yes, added or first_added is a better name.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> * Initial work to fill in the "deprecated" and "removal" information (i.e.<br>
> for a small number of existing options per project) would add strong value<br>
> to generated documentation.<br>
<br>
</span>Amen.<br>
<br>
Doug<br>
<span class=""><br>
> * Additional work to add the initial "released" information can be left to<br>
> an intro contributor task.  Information of an options existence in a<br>
> project can be automated via analysis of branches to provide details of the<br>
> seed info needed.<br>
><br>
> As for implementation, the use of a named tuple attribute for<br>
> oslo_config.cfg.Opt [1] is one approach.  Determining how to take advantage<br>
> of debtcollector and versionutils should be considered.<br>
><br>
> [1]<br>
> <a href="http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n636" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n636</a><br>
<br>
</span>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>