openstack/nova-specs - nova-specs - OpenDev: Free Software Needs Free Tools

Co-Authored-By: Takashi Natsume <takanattie@gmail.com>
Change-Id: Ie6688d8947c2a25de2a919b28bd26b5aef187796

Change-Id: I7913fc0bd027d883d11910ec26c007fb8868d404

Adds tooling and enhances README documentation around the backlog specs
process.
- To move a spec from the backlog to the current release, we can now use
 the ``move-spec`` tox target, e.g.
 tox -e move-spec -- [-n] [-v] specs/backlog/approved/great-idea.rst specs/train/approved
- To abandon a backlog spec - i.e. move it from specs/backlog/approved
 to the (new) specs/abandoned directory, we can now use the
 ``abandon-spec`` tox target, e.g.
 tox -e abandon-spec -- [-n] [-v] specs/backlog/it-was-a-great-idea.rst
These utilities will move the specified spec into the target directory
and create an appropriate redirect for it.
To make it so, this commit factors out a helper method that a) moves a
spec from one subdirectory to another and b) adds a redirect for it.
This is used by the existing ``move-implemented-specs`` utility as well
as the new ``move-spec`` and ``abandon-spec``.
While I was in here, I spruced up the verbose output (including for
move-implemented-specs) to be a bit more readable.
Change-Id: I322eecbacd5dc52accf6ac69c9fe1116be8c216f

Change-Id: I4225e37b889bf1a26d6d3ba197e524d3863c472e

Change-Id: I5aaa7d215491eba648862c61f597e78f6246eea7

Change-Id: I9cd0237d79398e30a423be6a01f05f146d642c04

Change-Id: I1fdf7b1e4fc14a883455a1052c4a502760844b08

The deadline for non-priority specs for Ocata has passed. Create the
Pike spec directories, such that folks can re-target their spec now for
review during the Pike cycle.
Change-Id: Ic4c13200b0418668f22ec0e4338b4f09d326abe0

The deadline for non-priority specs for Newton is almost here,
and as always there will be a large number of specs that do
not get approved. Any that remain in the Newton directory will
eventually get force abandoned. Opening up the Ocata directory
allows submitters who wish to re-target their effort to the
subsequent release, to move their spec across to the new
directory straight away enabling ongoing visibility & review.
Change-Id: I732576bb3c0e60ec130cdf73647fbc2f234905f7
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

The glob stanzas seem to not want .rst extension on includes. Drop it,
and the priorities list returns into the main index.
Change-Id: I8e6213425b602d2545cd6dbfc01bde7ea4bafd8c

Make the order of the priorities match the specifications order, where
we have the newest at the top.
Change-Id: I8a7bb38f27450a144d47388a65167ea9fdeda70f

Now we have the name for newton, we should open specs so people can
start targeting changes, either new or deferrals from Mitaka.
Change-Id: I84322ba6315316bf3d4ad3923067c5c8e7a9461e

As discussed at the Liberty mid-cycle, we should open the Mitaka specs so
that people can start targeting changes, either new or deferrals from
Liberty.
Change-Id: I6fe26e5665dcfd4e1a7fc6c0f7b7a9532e825640

Now that we are starting to get backlog specs, make it clear how one can
take it over and implement it.
* Make it clear on the landing page that backlog specs are looking for
 owners. Hopefully this will guide developers looking for a spec to
 work in to the right place.
* Explain how to take over a backlog spec.
Change-Id: Ia3585c515c115e073c00e3222fc6718da79792b9

Opening Liberty specs now allows us to let people move their unapproved Kilo
specs to Liberty and start working on our comments now.
Change-Id: I7f8391c20ced6fb09b453a8ce3987d141b643a35

This is copying what has been done for keystone:
If546724fd535db7753a372389c3f90f3b060d9bc
We add a place for people to add rough ideas, and a place to put specs
that are no longer going to be implemented by the proposer.
Includes updating the README to tell people where the backlog specs will
live.
We need to add a backlog spec before we can complete this change, this
is just a placeholder to advertise the backlog idea.
Change-Id: I667acfa422ef78bdc80efb279911091116b1c1f0

Need to split out the different releases so the index page will continue
to scale past the current two releases.
It required some rework how the specs are symlinked into the doc source
to allow for the release specific landing pages.
Change-Id: I31fa0b13e400dd202f5db3e63da7b7c8dbd40e68

We have previously published the kilo template here:
http://specs.openstack.org/openstack/nova-specs/specs/kilo-template.html
and have since updated it. But because we removed it from the toctree
it is not being updated on the website.
This change adds just the kilo template back into the toctree.
Change-Id: I8bdaef79439bf2f49a979c16de22c7aa6d7e2fcb

We don't want the templates to show up in the RSS feed, so exclude them
from being converted to HTML and listed in the toctree.
Change-Id: I1d50944fc37f27b5fc67316270cb281e3635b762

Note that this change includes an addition to the doc
index which is needed to bootstrap the approved directory
for Kilo. Without the change a sphinx warning about
the new spec rst file not being included anywhere causes the
build to fail. And applying the change with an empty approved
directory the pattern match fails and the build fails
Previously-approved: juno
Part of blueprint v2-on-v3-api
Change-Id: Ib8b259f69c9072520acecba167b7b31707bcadaa

Change-Id: Ia44ed986502be7252068f6bf2301e87ff75d1283

As discussed at our nova meetings, reorganize the juno specs into
three directories:
 - proposed: things proposed which weren't approved
 - approved: things we approved but didn't implement
 - implemented: things approved and implemented
The first I suspect is the most controversial. I've done this
because I worry about the case where a future developer wants to
pick up something dropped by a previous developer, but has trouble
finding previous proposed specifications on the topic. Note that
the actual proposed specs for Juno are adding in a later commit.
Change-Id: Idcf55ca37a83d7098dcb7c2971240c4e8fd23dc8

* Add section in kilo-template about project priorities (with a link to
 the kilo priorities document)
* Add in kilo priorities page. Currently this list is empty and we hope
 to fill it out at the summit
* Add the yaml file of priority blueprints that are ready for review.
 This is where we will track which priority blueprints need review.
Change-Id: I339e88f8055a63a9a9423d997da6581f977428c9

Now that we are publishing the docs from this repo at
http://specs.openstack.org/openstack/nova-specs/ add the README to set
of published documents.
Also cleanup README's rst formatting.
Change-Id: If8bf22bb025611b09269a5e4c1a3e49008f1e713

Just as we did at the beginning of the Havana and Icehouse dev cycles,
we need to reserve a range of DB migrations as the first DB change in
Juno. This will allow a range to be used for migration backports to
Icehouse if needed.
This is a straight forward blueprint that has been implemented for the
last two releases (Havana and Icehouse), so we can use this as a trial
run for our new blueprint review process before we open up all other
spec reviews.
Since this is the first Juno spec, re-add the Juno specs directory to
index.rst.
Related to blueprint backportable-db-migrations-juno.
Change-Id: I791c22b54ac8cd533d6fdc03ea93f12d4a907b23

Comment out specs/juno/* until a spec merges so that the docs can
build without errors.
There is still one warning about man pages with this change in place,
but I believe it will require a change to pbr to suppress.
Change-Id: Id63da83ce6e60c444322072e68c17c97cf983846

* Update to reflect new directory structure
* Drop maxdepth to 1, to make the page smaller, otherwise the index will
 include links to each section of each blueprint. And since each
 section will have the same name across bluepints this is useless.
Change-Id: I2a5d94ae26002a884033d27881394a795592fe3f

Update the nova-specs project to use sphinx. This will allow us to
still write our specs using rst, but also have a nice framework for
rendering and publishing the specs if we choose to.
Change-Id: Ib92231acb28bba44abafb7dd554404f542da13a7