[nova] "future" specs and blueprints
openstack at fried.cc
Tue Apr 2 13:48:58 UTC 2019
>> So yes, having this `specs/backlog/approved` does have a benefit (even
>> if it is 'marginal') than "leaving things as unmerged in Gerrit", where
>> every spec is a bland Gerrit URL, and their HTML renderings will have
>> gotten purged.
And hard to discover. Which of these (currently 64) unmerged nova specs
 are (a) for train, (b) from a previous release but still viable for
consideration, (c) dead? Today I can click through and look for file
paths to determine (a) or not-(a); but I have to go full Sherlock to
figure out (b) vs (c). Or count on the author to ask on IRC, add it to
the PTG agenda, etc.
> well the html rendering are not really useful for reviewign a spec
> you might want to look at the near the end when the content is correct so that
> the archive form looks nice but i would expects most peopel to read the rst
Totally personal preference. I read the rendered version any time it's
available. This is especially useful when things like seqdiag are used
( vs  if you please).
>> I agree with you that it gives a "crisper picture" of reality by not
>> muddying the waters of what is actually completed.
> well actully completed specs get copied into the implemented directory.
Right, so the distinction between "never approved" and "approved for
$release but not implemented" remains the same: unmerged gerrit review
vs specs/$release/approved (but not specs/$release/implemented),
respectively. What we're adding is "approved, but not for $release".
> i dont think we tend to get a lot of future reaching specs.
Part of what pushed me over the edge to want to do this right now was
 which I happened to know from talking to the author was intended for
But generally I agree, that's the exception rather than the rule.
> we get some
> that can not be completed due to developer or review bandwith in a singel
...this. We could make better use of the backlog directory to stage work
we know is going to take multiple cycles.
>> On the topic of merging 'nova-specs' into 'nova' repo, Jeremy raised
>> some really good points in his repsonse
One of the main original motivations was to remove the concept of
separate "spec cores". This was already accomplished a couple of weeks
ago by adding nova-core to nova-specs-core , and the remaining
potential benefits were deemed not worth the trouble.
More information about the openstack-discuss