[nova] "future" specs and blueprints

Jim Rollenhagen jim at jimrollenhagen.com
Wed Mar 27 20:45:20 UTC 2019

On Wed, Mar 27, 2019 at 3:47 PM Eric Fried <openstack at fried.cc> wrote:

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

Isn't this what the backlog directory[0] is for?


// jim

> -efried
> .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190327/588b4898/attachment.html>

More information about the openstack-discuss mailing list