[nova] "future" specs and blueprints

Sean Mooney smooney at redhat.com
Thu Mar 28 11:21:28 UTC 2019

On Thu, 2019-03-28 at 09:41 +0000, Bal√°zs Gibizer wrote:
> On Wed, Mar 27, 2019 at 10:10 PM, Eric Fried <openstack at fried.cc> wrote:
> > >  Isn't this what the backlog directory[0] is for?
> > > 
> > >  [0] 
> > > http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/backlog/approved
> > 
> > Mm, thanks Jim.
> > 
> > That appears to have been used for four months in 2015 (mitaka-ish?)
> > 
> > New proposal: How do folks feel about using the `backlog` directory
> > again? Presumably starting with scrubbing the four specs that are in 
> > it.
> I have no hard feelings about the backlog directory.
> We just need to make sure that we do some spring cleaning in that 
> directory for time to time. There could be features that make sense 
> today to put it to our backlog that will be invalidated by  design 
> decisions later.
> Also when movig a spec from backlog to approved directory  we need to 
> make sure to re-validate the assumptions in the spec based on the 
> actual state of nova.

so this is on the ptg agenda as topic but since it relevant to this thread

im not really opposed to the ideas put forward here but can we kill the nova-specs
repo and just move it to an in tree specs folder in the nova repo.

nova-specs-core now contains nova-core
so there is no real reason to keep it as a seperate repo.

all people who are directly members of nova-specs-core are also
nova cores and i dont think we plan to allow non nova cores approve
nova-specs in the future so keeping nova-spec seperate form the nova
code add little in my view and this will mean if implementation
diverge or only partaily implment a spec they can correct that in the nova
patch so that the two are never out of sync.

i am personally not a fan of updating spec after they have been appoved but
since that is something we allow it makes sense to me to make it easier too do.

> Cheers,
> gibi
> > 
> > -efried
> > .
> > 

More information about the openstack-discuss mailing list