[nova] "future" specs and blueprints
gmann at ghanshyammann.com
Mon Apr 1 01:54:12 UTC 2019
---- On Wed, 27 Mar 2019 14:45:02 -0500 Eric Fried <openstack at fried.cc> wrote ----
> 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).
Thanks for bringing this up.
What will be the conditions or criteria of the above two scenarios?
- Review bandwidth?
- Author (contributors) wish not to complete the code in the cycle when he/she
is proposing the spec for? I mean do we have any scenario where spec author
says "please approve my spec in this cycle but I will not start the code in this cycle
so consider this a future spec"
- Technical scope etc ?
- Anything else ?
IMO, the first two scenarios should not be the reason to ask people to propose
your spec in future/ dir. For other scenarios, we should clearly say "NO: as of
now due to xyz reason so rejected or suggestion for repropose" etc.
future/ dir idea is good but main challenge it can face is "how many people going
to review the future/ items' because I feel everyone is so busy with their current
> - If a contributor wants to start work on a spec for a future release,
> they can propose it directly to the future/ path.
+1, this is a nice idea to start the early discussion/feedback etc.
> - 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?
More information about the openstack-discuss