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... [2] https://review.openstack.org/#/c/572583/11/specs/rocky/approved/reshape-prov... [3] https://review.openstack.org/#/c/648665/ [4] https://review.openstack.org/#/admin/groups/302,members