<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font size="-1"><tt>Updating this based on everything that's
happened in the last day or two.<br>
<br>
At this point, every blueprint that *isn't* targeted to Stein
has been ported to an RFE bug report [0]. Each one should
contain links to any relevant information that lived in the
blueprint. Only stein-specific blueprints are left [1], which
will be completed at the end of this release. There is a patch
up to the contributor guide that describes the process for
requesting new features [2]. Please have a look and let me know
if anything is missing. The etherpad should be completely
up-to-date [3] with pointers to all blueprints we touched, in
case you want to see why we classified a particular blueprint a
certain way.<br>
<br>
Most of the RFE bugs still require some investigation, but we
can use our usual process for validating or invalidating them,
with justification in comments. Don't hesitate to ask if you
have questions about this work.<br>
<br>
[0] <a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/keystone/+bugs?field.tag=rfe">https://bugs.launchpad.net/keystone/+bugs?field.tag=rfe</a><br>
[1] <a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/keystone">https://blueprints.launchpad.net/keystone</a><br>
[2] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/637311/">https://review.openstack.org/#/c/637311/</a><br>
[3] <a class="moz-txt-link-freetext" href="https://etherpad.openstack.org/p/keystone-blueprint-cleanup">https://etherpad.openstack.org/p/keystone-blueprint-cleanup</a><br>
</tt></font><br>
<div class="moz-cite-prefix">On 2/14/19 10:24 AM, Lance Bragstad
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:07f1042a-1f84-87a5-1505-38ce1705429c@gmail.com">
<pre class="moz-quote-pre" wrap="">Sounds good to me. We should probably find a home for this information.
Somewhere in our contributor guide, perhaps?
On 2/14/19 10:00 AM, Colleen Murphy wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Thu, Feb 14, 2019, at 4:50 PM, Morgan Fainberg wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I think a `git blame` or history of the deprecated release note is nice, it
centralizes out tracking of removed/deprecated items to the git log itself
rather than some external tracker that may or may not be available forever.
This way as long as the git repo is maintained, our tracking for a given
release is also tracked.
Specs and bugs are nice, but the deprecated bug # for a given release is
fairly opaque. Other bugs might have more context in the bug, but if it's
just a list of commits, I don't see a huge win.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I'm also +1 on just keeping it in the release notes.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Thu, Feb 14, 2019, 10:28 Lance Bragstad <<a class="moz-txt-link-abbreviated" href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Thu, Feb 14, 2019, 06:07 Colleen Murphy <<a class="moz-txt-link-abbreviated" href="mailto:colleen@gazlene.net">colleen@gazlene.net</a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">What should we do about tracking "deprecated-as-of-*" and
"removed-as-of-*" work? I never liked how this was done with blueprints but
I'm not sure how we would do it with bugs. One tracking bug for all
deprecated things in a cycle? One bug for each? A Trello/Storyboard board
or etherpad? Do we even need to track it with an external tool - perhaps we
can just keep a running list in a release note that we add to over the
cycle?
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">I agree. The solution that is jumping out at me is to track one bug for
deprecated things and one for removed things per release, so similar to
what we do now with blueprints. We would have to make sure we tag commits
properly, so they are all tracked in the bug report. Creating a bug for
everything that is deprecated or removed would be nice for capturing
specific details, but it also feels like it will introduce more churn to
the process.
I guess I'm assuming there are users that like to read every commit that
has deprecated something or removed something in a release. If we don't
need to operate under that assumption, then a release note would do just
fine and I'm all for simplifying the process.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">I think the reason we have release notes is so people *don't* have to read every commit.
Colleen
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<br>
</body>
</html>