[nova] "future" specs and blueprints

Sean Mooney smooney at redhat.com
Tue Apr 2 11:44:39 UTC 2019


On Tue, 2019-04-02 at 12:56 +0200, Kashyap Chamarthy wrote:
> On Wed, Mar 27, 2019 at 04:10:09PM -0500, Eric Fried wrote:
> 
> (Just catching up with this thread, post-PTO.)
> 
> [...]
> 
> > New proposal: How do folks feel about using the `backlog` directory
> > again? Presumably starting with scrubbing the four specs that are in it.
> 
> Hi,
> 
> I get a nagging feeling at the back of my head whenever I see specs in
> the "approved" directory for a given release, but they are not
> completed, or needs to be re-proposed for any number of good reasons.
> 
> 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.
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.
> 
> 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.
i dont think we tend to get a lot of future reaching specs. we get some
that can not be completed due to developer or review bandwith in a singel
cycle or that end up haveing depencies that mean the get punted to a follow
up release. i have found most feature related to numa/nfv often take 2-3 cycles
to fully land but that is generally not by intent.
>   Plus it gives us a
> clean, rendered overview of what ideas we thought were worth pursuing
> (which, as Gibi noted, will be re-evaluated at the time of transition
> from "backlog" to "approved").  And, as you stated in the "Backlog
> specifications" section[2] in the README, it can act as a robust
> starting point for those (especially for experienced developers) who
> want to get involved with Nova.
> 
>         * * *
> 
> On the topic of merging 'nova-specs' into 'nova' repo, Jeremy raised
> some really good points in his repsonse[2].  Unless I see his points
> addressed with compelling answers, I'd vote for keeping the 'nova-specs'
> repo separate.
i tought i had fully adressed all of jeremy's questions in 
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004317.html
i abandonded that direction simply because peopel seamed to feel the
git subtree magic need to create a muli root git tree to extract
the spec directory form nova-specs and add it to nova was more hassel then it was worth.
if i missed  one of jeremy's point please respond but i didnt see any of the as a blocker
for this work but perserving the history is something im willing to conceed is slightly
more effort then i would like given the rewards.

>   (I should admit that I don't know what was the original
> impetus for merging it into the 'nova' repo.)
> 
> [1] http://logs.openstack.org/00/648800/3/check/openstack-tox-docs/e601952/html/readme.html#backlog-specifications
> [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004314.html
> 
> [...]
> 




More information about the openstack-discuss mailing list