<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 2/14/19 5:47 AM, Morgan Fainberg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGnj6avrRzK-kwc1q0vx9bUR6tCYT16-+4QcNSNooyRaYXKSTQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Rethinking my last email... Go with just release
notes, no need for a bug.</div>
</blockquote>
<br>
<tt>The only thing we lose with this would be a place to see every
commit that deprecated or removed something in a release (short of
doing a git blame on the release note). We could still do this
with bugs and we could drive the tracking with Partial-Bug in each
commit message. We need to make sure to formally close the bug
however at the end of the release if we don't close it with a
commit using Closes-Bug. In my experience, we rarely stage all
these commits at once. They're usually proposed haphazardly
throughout the release as people have cycles.</tt><br>
<br>
<blockquote type="cite"
cite="mid:CAGnj6avrRzK-kwc1q0vx9bUR6tCYT16-+4QcNSNooyRaYXKSTQ@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Feb 14, 2019, 06:46 Morgan Fainberg <<a
href="mailto:morgan.fainberg@gmail.com"
moz-do-not-send="true">morgan.fainberg@gmail.com</a> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>I would go for one tracking bug per cycle or we could
also just lean on the release notes instead of having a
direct bug. <br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Feb 14, 2019, 06:07 Colleen
Murphy <<a href="mailto:colleen@gazlene.net"
target="_blank" rel="noreferrer"
moz-do-not-send="true">colleen@gazlene.net</a>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On
Wed, Feb 13, 2019, at 8:56 PM, Lance Bragstad wrote:<br>
> Over the last couple of years, our launchpad
blueprints have grown<br>
> unruly [0] (~77 blueprints a few days ago). The
majority of them were in<br>
> "New" status, unmaintained, and several years old
(some dating back to<br>
> 2013). Even though we've been using
specifications [1] for several<br>
> years, people still get confused when they see
conflicting or inaccurate<br>
> blueprints. After another person tripped over a
duplicate blueprint this<br>
> week, cmurphy, vishakha, and I decided to devote
some attention to it.<br>
> We tracked the work in an etherpad [2] - so we
can still find links to<br>
> things.<br>
> <br>
> First, if you are the owner of a blueprint that
was marked as<br>
> "Obsolete", you should see a comment on the
whiteboard that includes a<br>
> reason or justification. If you'd like to
continue the discussion about<br>
> your feature request, please open a specification
against the<br>
> openstack/keystone-specs repository instead. For
historical context,<br>
> when we converted to specifications, we were only
supposed to create<br>
> blueprints for tracking the work after the
specification was merged.<br>
> Unfortunately, I don't think this process was
ever written down, which<br>
> I'm sure attributed to blueprint bloat over the
years.<br>
> <br>
> Second, if you track work regularly using
blueprints or plan on<br>
> delivering something for Stein, please make sure
your blueprint in<br>
> Launchpad is approved and tracked to the
appropriate release (this<br>
> should already be done, but feel free to double
check). The team doesn't<br>
> plan on switching processes for feature tracking
mid-release. Instead,<br>
> we're going to continue tracking feature work
with launchpad blueprints<br>
> for the remainder of Stein. Currently, the team
is leaning heavily<br>
> towards using RFE bug reports for new feature
work, which we can easily<br>
> switch to in Train. The main reason for this
switch is that bug comments<br>
> are immutable with better timestamps while
blueprint whiteboards are<br>
> editable to anyone and not timestamped very well.
We already have<br>
> tooling in place to update bug reports based on
commit messages and that<br>
> will continue to work for RFE bug reports.<br>
> <br>
> Third, any existing blueprints that aren't
targeted for Stein but are<br>
> good ideas, should be converted to RFE bug
reports. All context from the<br>
> blueprint will need to be ported to the bug
report. After a sufficient<br>
> RFE bug report is opened, the blueprint should be
marked as "Superseded"<br>
> or "Obsolete" *with* a link to the newly opened
bug. While this is<br>
> tedious, there aren't nearly as many blueprints
open now as there were a<br>
> couple of days ago. If you're interested in
assisting with this effort,<br>
> let me know.<br>
> <br>
> Fourth, after moving non-Stein blueprints to RFE
bugs, only Stein<br>
> related blueprints should be open in launchpad.
Once Stein is released,<br>
> we'll go ahead disable keystone blueprints.<br>
> <br>
> Finally, we need to overhaul a portion of our
contributor guide to<br>
> include information around this process. The goal
should be to make that<br>
> documentation clear enough that we don't have
this issue again. I plan<br>
> on getting something up for review soon, but I
don't have anything<br>
> currently, so if someone is interested in taking
a shot at writing this<br>
> document, please feel free to do so. Morgan has a
patch up to replace<br>
> blueprint usage with RFE bugs in the
specification template [3].<br>
> <br>
> We can air out any comments, questions, or
concerns here in the thread.<br>
<br>
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?<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
<tt>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.<br>
<br>
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.<br>
</tt><br>
<blockquote type="cite"
cite="mid:CAGnj6avrRzK-kwc1q0vx9bUR6tCYT16-+4QcNSNooyRaYXKSTQ@mail.gmail.com">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks for tackling this cleanup work.<br>
<br>
> <br>
> Thanks,<br>
> <br>
> Lance<br>
> <br>
> [0] <a
href="https://blueprints.launchpad.net/keystone"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">https://blueprints.launchpad.net/keystone</a><br>
> [1] <a
href="http://specs.openstack.org/openstack/keystone-specs/"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">http://specs.openstack.org/openstack/keystone-specs/</a><br>
> [2] <a
href="https://etherpad.openstack.org/p/keystone-blueprint-cleanup"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">https://etherpad.openstack.org/p/keystone-blueprint-cleanup</a><br>
> [3] <a
href="https://review.openstack.org/#/c/625282/"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">https://review.openstack.org/#/c/625282/</a><br>
> Email had 1 attachment:<br>
> + signature.asc<br>
> 1k (application/pgp-signature)<br>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>