Open Stack

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

This.

And hard to discover. Which of these (currently 64) unmerged nova specs
[0] 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
> directly.

Totally personal preference. I read the rendered version any time it's
available. This is especially useful when things like seqdiag are used
([1] vs [2] 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
[3] which I happened to know from talking to the author was intended for
post-Train.

But generally I agree, that's the exception rather than the rule.

However...

> we get some
> that can not be completed due to developer or review bandwith in a singel
> cycle

...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 [4], and the remaining
potential benefits were deemed not worth the trouble.

-efried

[0]
https://review.openstack.org/#/q/project:openstack/nova-specs+status:open
[1]
http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/reshape-provider-tree.html#proposed-change
[2]
https://review.openstack.org/#/c/572583/11/specs/rocky/approved/reshape-provider-tree.rst@48
[3] https://review.openstack.org/#/c/648665/
[4] https://review.openstack.org/#/admin/groups/302,members