Add a mandatory 'Feature Liaison' section to the spec template,
requiring specs to be sponsored by an experienced nova developer (not
necessarily an actual core -- this is explained in the docs).
This in an effort to mitigate several problems noted in previous
development cycles:
- Inexperienced contributors don't understand how nova dev culture works
- "Nobody but me cares about my feature"
- "Whom should I ask for reviews first, especially if I don't even know
whether I'm ready for them?"
The current commit edits already-approved specs to include the new
section.
The main README is updated with a new section to describe more
thoroughly what this feature liaison thing is. At the same time, since
this impacts several aspects of the process, the remainder of the README
is tweaked and updated accordingly. Of note:
* We're now going to make distinct use of the launchpad blueprint's
"Definition" and "Direction" fields. As such, we can still decide to
defer a blueprint whose spec is merged in the 'approved' directory.
(Which really isn't different than what we were doing before; it's
just that now we can do it for reasons other than "oops, this didn't
get finished in time".)
* The single-core-approval rule for previously approved specifications
is removed [1].
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-10-03.log.html#t2019-10-03T16:08:05
Change-Id: Ibb3a2990e23aecf3ea7ebc1b47413396b676f2d6
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
This patch fixes rendering sub-directories as expected in README.
The directories are rendered in one line.
Change-Id: Ia7e29db553e2c80a63976b3de4b285b098b2a055
This adds a script and tox target to automatically process and
move approved specs for a given release into the related implemented
directory for the same release. It uses launchpadlib to check the
status on the spec (blueprint) and only moves those that are
complete.
For example, to run this:
tox -r -e move-implemented-specs -- -n -v newton
Change-Id: Ib431f62101b90abecce86f60ba7acbba11e09533
Add more text around how we move specs around in the directory
structure, and remove some redundant text. Add more headings to
improve the flow of the document as well.
Change-Id: I607d40ff27685cb32855ee876f48830c4d9f1d15
It seems there is a need to be more explicit with some of our
review policies, so this change is an attempt to make our
existing policies clearer.
Change-Id: Ib1475f9075dc5d3c106293ddd35be5d3c96b6de4
The README.rst instructions say to put the proposed spec under
'specs/<release>' but really we want them under
'specs/<release>/approved' so let's make that explicit.
Change-Id: I9e124efd4d13168d97b94fb4ac6da7ec7b0acf18
Replace URLs for workflow documentation to appropriate parts of the
OpenStack Project Infrastructure Manual.
Change-Id: Ib46b73ae87321f48edb47ab8a12ea0d143b84825
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
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
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
The README was recently updated to note that you can run 'tox' to
validate the docs. This also generates HTML, so note that as it's
also nice to be able to view your spec in its rendered format.
Change-Id: I8350d8066b6d68793101ea3bea88a91e9dc17b98
People not familiar with the nova-specs system might
get confused when getting Jenkins failures for their
specification.
It's worth providing the test command in the README file to
allow people to fix these issues before submitting the
patch to Gerrit.
Change-Id: I13954599b057790ab5ae7c83493c3193acf8dc22
Add a link so people can find the current blueprint process. This
ways its more obvious that we still use launchpad to track
blueprints.
At the same time, remove the Milestones section from the template,
to ensure all tracking is in launchpad.
Change-Id: I1ef3d0d010deddae4eb398e801810137276ebffb
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
This commit introduces the proposed layout for this repository. The
next step after this will be to start defining the expected layout of
a spec and provide some templates.
Change-Id: I4b38d75802f3c7feef98639dfddd1898e564145f