<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">Le 18/11/2015 16:34, Sean Dague a
écrit :<br>
</div>
<blockquote cite="mid:564C9A7E.6080004@dague.net" type="cite">
<pre wrap="">On 11/17/2015 05:31 PM, Matt Riedemann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 11/17/2015 2:05 PM, Sylvain Bauza wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Le 17/11/2015 20:25, Sean Dague a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">On 11/17/2015 01:48 PM, Matt Riedemann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 11/17/2015 11:28 AM, Alexis Lee wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Often in Nova we introduce an option defaulted off (so as not to break
people) but then we want to make it default in the next release.
Someone suggested an opt flag to mark this but I don't know what
impact
they wanted it to have. IE how the user should be alerted about the
presence of these flagged options.
If you are that person, or have opinions on this, please reply :)
Alexis (lxsli)
</pre>
</blockquote>
<pre wrap="">There is the deprecated_for_removal kwarg, but that doesn't fit here.
There is the DeprecatedOpt, but that's for moving/renaming options. So
this is something else, like deprecated_default or
pending_default_change or something.
</pre>
</blockquote>
<pre wrap="">Honestly, with reno now we could probably just add a release note in
when we add it. That's more likely for us to not loose a thing like
that.
-Sean
</pre>
</blockquote>
<pre wrap="">
Agreed, it's now far easier to ask for having a release note within the
change, so the operators can just look at that. It also seems to me far
better for them to check the release notes rather than trying to see the
huge nova.conf file...
-Sylvain
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<pre wrap="">
Sure, a release note is justified, just like when we deprecate or rename
an option.
The thing I like about the deprecated_for_removal kwarg is the warning
that gets logged when you are still using the thing. I'm sure people see
release notes for deprecated things and say, I'll add a TODO to clean
this up in our tooling, but then get busy and forget about it until they
break. The annoying warning is a constant indicator that this is
something you need to move off of sooner rather than later.
</pre>
</blockquote>
<pre wrap="">
Yes, I like also using the deprecated_for_removal flags, and I don't
want to change that.
This is just for the case of "we're going to change the default on the
next release". I think in that case, a release note is the right thing.
We don't need new fancy code for that.
</pre>
</blockquote>
<br>
I usually hate saying just +1 in an email, but...<br>
<br>
+1<br>
<blockquote cite="mid:564C9A7E.6080004@dague.net" type="cite">
<pre wrap="">
-Sean
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>