Open Stack

On Wed, Feb 13, 2019, at 8:56 PM, Lance Bragstad wrote:
> Over the last couple of years, our launchpad blueprints have grown
> unruly [0] (~77 blueprints a few days ago). The majority of them were in
> "New" status, unmaintained, and several years old (some dating back to
> 2013). Even though we've been using specifications [1] for several
> years, people still get confused when they see conflicting or inaccurate
> blueprints. After another person tripped over a duplicate blueprint this
> week, cmurphy, vishakha, and I decided to devote some attention to it.
> We tracked the work in an etherpad [2] - so we can still find links to
> things.
> 
> First, if you are the owner of a blueprint that was marked as
> "Obsolete", you should see a comment on the whiteboard that includes a
> reason or justification. If you'd like to continue the discussion about
> your feature request, please open a specification against the
> openstack/keystone-specs repository instead. For historical context,
> when we converted to specifications, we were only supposed to create
> blueprints for tracking the work after the specification was merged.
> Unfortunately, I don't think this process was ever written down, which
> I'm sure attributed to blueprint bloat over the years.
> 
> Second, if you track work regularly using blueprints or plan on
> delivering something for Stein, please make sure your blueprint in
> Launchpad is approved and tracked to the appropriate release (this
> should already be done, but feel free to double check). The team doesn't
> plan on switching processes for feature tracking mid-release. Instead,
> we're going to continue tracking feature work with launchpad blueprints
> for the remainder of Stein. Currently, the team is leaning heavily
> towards using RFE bug reports for new feature work, which we can easily
> switch to in Train. The main reason for this switch is that bug comments
> are immutable with better timestamps while blueprint whiteboards are
> editable to anyone and not timestamped very well. We already have
> tooling in place to update bug reports based on commit messages and that
> will continue to work for RFE bug reports.
> 
> Third, any existing blueprints that aren't targeted for Stein but are
> good ideas, should be converted to RFE bug reports. All context from the
> blueprint will need to be ported to the bug report. After a sufficient
> RFE bug report is opened, the blueprint should be marked as "Superseded"
> or "Obsolete" *with* a link to the newly opened bug. While this is
> tedious, there aren't nearly as many blueprints open now as there were a
> couple of days ago. If you're interested in assisting with this effort,
> let me know.
> 
> Fourth, after moving non-Stein blueprints to RFE bugs, only Stein
> related blueprints should be open in launchpad. Once Stein is released,
> we'll go ahead disable keystone blueprints.
> 
> Finally, we need to overhaul a portion of our contributor guide to
> include information around this process. The goal should be to make that
> documentation clear enough that we don't have this issue again. I plan
> on getting something up for review soon, but I don't have anything
> currently, so if someone is interested in taking a shot at writing this
> document, please feel free to do so. Morgan has a patch up to replace
> blueprint usage with RFE bugs in the specification template [3].
> 
> We can air out any comments, questions, or concerns here in the thread.

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?

Thanks for tackling this cleanup work.

> 
> Thanks,
> 
> Lance
> 
> [0] https://blueprints.launchpad.net/keystone
> [1] http://specs.openstack.org/openstack/keystone-specs/
> [2] https://etherpad.openstack.org/p/keystone-blueprint-cleanup
> [3] https://review.openstack.org/#/c/625282/
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)