[nova] "future" specs and blueprints

Eric Fried openstack at fried.cc
Wed Mar 27 19:45:02 UTC 2019


All-

It seems like we don't have a great way of looking at a blueprint and
saying, "this looks like a good idea, and yes we want to do it, but
we're not going to be able to prioritize it for this release." Sometimes
we just leave those blueprints "unspecified" and their specs stay open
in limbo. And some blueprints we'll approve for the current series, and
merge the spec under $current_cycle/approved, but not really intend to
get the work completed. And at the end of the release, those pieces
muddy our completion stats. It would be nice if those stats reflected
only work we got done that we *intended* to get done.

I'm not bringing this up just for the sake of making numbers pretty; it
would just be nice to have a crisp picture of the work slated for the
current release. And also a way for contributors to propose specs they
*don't* intend for the current series, but still want to start
discussing (I happen to know of at least one example of this for Train).
And also a way to keep track of work we know we want to do eventually,
just not now.

=== TL;DR >>>
So I'd like to propose that we set up a "future" series in Launchpad,
and a corresponding subdirectory in the specs repo.
=== TL;DR <<<

The process would be pretty much as you would expect, including (but not
limited to):

- If we decide (e.g. at the PTG) that we like a spec that's proposed
under $current/approved, but won't have time for it in the current
series, we'll ask the author to move it to future/ and make sure the
History section includes "$current: proposed and approved for 'future'".
- If we decide in mid-release that we want to defer a blueprint, we can
propose a patch to move it from $current/approved to future/ (including
a redirect).
- If a contributor wants to start work on a spec for a future release,
they can propose it directly to the future/ path.
- Every cycle when setting goals we can skim through the 'future' items
to see if any should be pulled in. In which case we propose a patch to
move the file from future/ to $current/approved (including a redirect)
which we can fast-approve.
- If we decide to flush a spec from 'future', we can move it to a
'rejected' (or 'abandoned'? bikeshed away) folder - but we can sort this
part of the process out later.

How do folks feel about this idea?

-efried
.



More information about the openstack-discuss mailing list