This is an attempt to formalize our governance structure, but it's
not really an attempt to change it. The goal has been to create
a governance structure which most closely resembles how we have
been operating for the past several years.
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.
And start using it. Added some common terms to glossary.
I have not found a lot of source material yet to suggest the best
way to incorporate use of a glossary into the text, especially with
very frequently used technical terms like we have in some parts of
this documentation. So here are the guidelines I'm trying out:
* If the term is being defined in the text, don't like to the glossary
(that would be redundant), but do emphasize it with *italics* the
first time it appears in that definition. Subsequent uses within
the same subsection should be in regular type.
* If it's being used (but not defined) in the text, link the first usage
within a subsection to the glossary, but subsequent uses should be
in regular type.
* Be cognizant of how readers may jump to link targets within the text,
so be liberal in considering that once you cross a link target,
you may be in a new "subsection" for the above guideline.
This change also alters some use of literals to make them more consistent:
* Filenames and scalar values of attributes (not special keyword values
like 'independent') should be ``literal``.
* Most references to attribute names should be via the :attr: role, however,
for abbreviated local references (ie, to the current or previous attribute)
use **bold** to maintain the same style but without the long name and link.
Also, correct some spelling.
To avoid confusion with nodepool-launcher, we've decided to rename
zuul-launcher to zuul-executor.
Signed-off-by: Paul Belanger <email@example.com>
Connect it to Zuul via Gearman. Any number of mergers may be
Directly find the pipeline for a build when processing a result,
so that the procedure is roughly the same for build and merge
The timer trigger currently requires the gerrit trigger also be
configured. Make that explicit inside of the timer trigger so
that the scheduler API interaction with triggers is cleaner.
Allows multiple reports per a patchset to be sent to pluggable
destinations. These are configurable per pipeline and, if not
specified, defaults to the legacy behaviour of reporting back only
Having multiple reporting methods means only certain success/failure
/start parameters will apply to certain reporters. Reporters are
listed as keys under each of those actions.
This means that each key under success/failure/start is a reporter and the
dictionaries under those are sent to the reporter to deal with.
Remove the Jenkins launcher and add a new Gearman launcher (designed
to be compatible with Jenkins) in its place.
See the documentation for how to set up the Gearman Plugin for