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.
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?