<div dir="auto">Rethinking my last email... Go with just release notes, no need for a bug.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 14, 2019, 06:46 Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">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">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>
<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">https://blueprints.launchpad.net/keystone</a><br>
> [1] <a href="http://specs.openstack.org/openstack/keystone-specs/" rel="noreferrer noreferrer noreferrer" target="_blank">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">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">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>