Use reno for release notes

The OpenStack Release team has created a great release notes management
tool that integrates with Sphinx. Start using it. For reference on how
to use it, see http://docs.openstack.org/developer/reno/

Add an initial release note with no contents so that the build flow and
docs integration can be verified. The note file can be removed later.

Change-Id: I254cd220fc8c0c06ee87f84f1fb5cbe3244f0fed
This commit is contained in:
Monty Taylor 2015-12-30 13:27:33 -06:00
parent 1243cf75f4
commit f0314feb8c
No known key found for this signature in database
GPG Key ID: 7BAE94BC7141A594
8 changed files with 54 additions and 58 deletions

View File

@ -1,58 +0,0 @@
Since 2.0.0:
* The push_change_refs option which specified that Zuul refs should be
pushed to Gerrit has been removed.
* Git merge operations are now performed in a separate process. Run
at least one instance of the ``zuul-merger`` program which is now
included. Any number of Zuul-Mergers may be run in order to
distribute the work of speculatively merging changes into git and
serving the results to test workers. This system is designed to
scale out to many servers, but one instance may be co-located with
the Zuul server in smaller deployments. Several configuration
options have moved from the ``zuul`` section to ``merger``.
Since 1.3.0:
* The Jenkins launcher is replaced with Gearman launcher. An internal
Gearman server is provided, and there is a Gearman plugin for
Jenkins, so migration to the new system should be fairly
straightforward. See the Launchers section of the documentation for
details.
* The custom parameter function signature has changed. It now takes a
QueueItem as the first argument, rather than the Change. The
QueueItem has the full context for why the change is being run
(including the pipeline, items ahead and behind, etc.). The Change
is still available via the "change" attribute on the QueueItem. The
second argument is now the Job that is about to be run, and the
parameter dictionary is shifted to the third position.
* The ZUUL_SHORT_* parameters have been removed (the same
functionality may be achieved with a custom parameter function that
matches all jobs).
* Multiple triggers are now supported (currently Gerrit and a simple
Timer trigger are supported). Your layout.yaml file will need to
change to add the key "gerrit:" inside of the "triggers:" list to
specify a Gerrit trigger (and facilitate adding other kinds of
triggers later). See the sample layout.yaml and Zuul section of the
documentation.
* Some statsd keys have changed in a backwards incompatible way:
* The counters and timers of the form zuul.job.{name} is now split
into several keys of the form:
zuul.pipeline.{pipeline-name}.job.{job-name}.{result}
* Job names in statsd keys now have the '_' character substituted
for the '.' character.
* The layout.yaml structure has changed to introduce configurable
reporters. This requires restructuring the start/success/failure
actions to include a dictionary of reporters and their parameters.
See reporters in the docs and layout.yaml-sample.
* The zuul_url configuration option is required in zuul.conf. It
specifies the URL of the git repositories that should be used by
workers when fetching Zuul refs and is passed to the workers as the
ZUUL_URL parameter. It should probably be set to
"http://zuul-host-name/p/".

View File

@ -34,6 +34,7 @@ extensions = [
'zuul_sphinx',
'zuul.sphinx.ansible',
'zuul.sphinx.zuul',
'reno.sphinxext',
]
#extensions = ['sphinx.ext.intersphinx']
#intersphinx_mapping = {'python': ('http://docs.python.org/2.7', None)}

View File

@ -17,3 +17,4 @@ Zuul, though advanced users may find it interesting.
docs
ansible
javascript
releasenotes

View File

@ -0,0 +1,41 @@
Release Notes
=============
Zuul uses `reno`_ for release note management. When adding a noteworthy
feature, fixing a noteworthy bug or introducing a behavior change that a
user or operator should know about, it is a good idea to add a release note
to the same patch.
Installing reno
---------------
reno has a command, ``reno``, that is expected to be run by developers
to create a new release note. The simplest thing to do is to install it locally
with pip:
.. code-block:: bash
pip install --user reno
Adding a new release note
-------------------------
Adding a new release note is easy:
.. code-block:: bash
reno new releasenote-slug
Where ``releasenote-slug`` is a short identifier for the release note.
reno will then create a file in ``releasenotes/notes`` that contains an
initial template with the available sections.
The file it creates is a yaml file. All of the sections except for ``prelude``
contain lists, which will be combined with the lists from similar sections in
other note files to create a bulleted list that will then be processed by
Sphinx.
The ``prelude`` section is a single block of text that will also be
combined with any other prelude sections into a single chunk.
.. _reno: https://docs.openstack.org/reno/latest/

View File

@ -28,6 +28,7 @@ Contents:
user/index
admin/index
developer/index
releasenotes
.. toctree::
:hidden:

View File

@ -0,0 +1,5 @@
=============
Release Notes
=============
.. release-notes::

View File

@ -0,0 +1,4 @@
---
prelude: >
This is a placeholder releasenote. It should be removed as soon as we have
a real one.

View File

@ -9,6 +9,7 @@ testrepository>=0.0.17
testtools>=0.9.32
sphinxcontrib-programoutput
sphinx-autodoc-typehints
reno>=2.5.0 # Apache-2.0
mock
PyMySQL
mypy