a19cd28f20
Change I49b659948f35381a44e2fb5f91dd6bf9e8ef619e provided a mechanism to
include the release note cache into generated sdists. Unfortunately,
attempting to build documentation with these tarballs generates the
following error:
Exception occurred:
File ".../lib/python3.7/site-packages/dulwich/repo.py", line 1004, in discover
"No git repository was found at %(path)s" % dict(path=start)
dulwich.errors.NotGitRepository: No git repository was found at PATH
This is because we're attempting to find the root of the git repo using
dulwich, which clearly isn't possible outside of a git repo.
Work around this by falling back to a search. We consider three options:
'.', '..', and '../..', which will handle calling Sphinx from the
rootdir, a 'docs' dir, and a 'docs/source' dir, which seem to be the
most common configurations.
We have no test coverage of the Sphinx integration so this is tested
manually.
Change-Id: Ic3a8ab8b127fd5bf51b91ac6e83d459ffc087fc4
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Story: #1520096
Task: #6724
|
||
|---|---|---|
| doc/source | ||
| examples/notes | ||
| releasenotes/notes | ||
| reno | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| bindep.txt | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| lower-constraints.txt | ||
| MANIFEST.in | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
reno: A New Way to Manage Release Notes
Reno is a release notes manager designed with high throughput in mind, supporting fast distributed development teams without introducing additional development processes. Our goal is to encourage detailed and accurate release notes for every release.
Reno uses git to store its data, along side the code being described. This means release notes can be written when the code changes are fresh, so no details are forgotten. It also means that release notes can go through the same review process used for managing code and other documentation changes.
Reno stores each release note in a separate file to enable a large number of developers to work on multiple patches simultaneously, all targeting the same branch, without worrying about merge conflicts. This cuts down on the need to rebase or otherwise manually resolve conflicts, and keeps a development team moving quickly.
Reno also supports multiple branches, allowing release notes to be back-ported from master to maintenance branches together with the code for bug fixes.
Reno organizes notes into logical groups based on whether they describe new features, bug fixes, known issues, or other topics of interest to the user. Contributors categorize individual notes as they are added, and reno combines them before publishing.
Notes can be styled using reStructuredText directives, and reno's Sphinx integration makes it easy to incorporate release notes into automated documentation builds.
Notes are automatically associated with the release version based on the git tags applied to the repository, so it is not necessary to track changes manually using a bug tracker or other tool, or to worry that an important change will be missed when the release notes are written by hand all at one time, just before a release.
Modifications to notes are incorporated when the notes are shown in their original location in the history. This feature makes it possible to correct typos or otherwise fix a published release note after a release is made, but have the new note content associated with the original version number. Notes also can be deleted, eliminating them from future documentation builds.
Project Meta-data
- Free software: Apache license
- Documentation: https://docs.openstack.org/reno/latest/
- Source: https://git.openstack.org/cgit/openstack/reno
- Bugs: https://storyboard.openstack.org/#!/project/933
- IRC: #openstack-release on freenode