From b586a6a20e5794dce0f0449847b3726b39451141 Mon Sep 17 00:00:00 2001 From: Ioannis Cherouvim <743305+cherouvim@users.noreply.github.com> Date: Fri, 20 Sep 2019 21:19:38 +0300 Subject: [PATCH] docs: List items consistency Capitalized list items and finished them with a full stop. This was inconsistent. --- docs/development.rst | 88 ++++++++++++++++++++++---------------------- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index 88606204d..f7953e741 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -17,33 +17,33 @@ Contributions Some guidance for contributors: -- discuss changes on the GitHub issue tracker, on IRC or on the mailing list +- Discuss changes on the GitHub issue tracker, on IRC or on the mailing list. -- make your PRs on the ``master`` branch (see `Branching Model`_ for details) +- Make your PRs on the ``master`` branch (see `Branching Model`_ for details). -- do clean changesets: +- Do clean changesets: - - focus on some topic, resist changing anything else. - - do not do style changes mixed with functional changes. - - try to avoid refactorings mixed with functional changes. - - if you need to fix something after commit/push: + - Focus on some topic, resist changing anything else. + - Do not do style changes mixed with functional changes. + - Try to avoid refactorings mixed with functional changes. + - If you need to fix something after commit/push: - - if there are ongoing reviews: do a fixup commit you can + - If there are ongoing reviews: do a fixup commit you can squash into the bad commit later. - - if there are no ongoing reviews or you did not push the + - If there are no ongoing reviews or you did not push the bad commit yet: amend the commit to include your fix or merge the fixup commit before pushing. - - have a nice, clear, typo-free commit comment - - if you fixed an issue, refer to it in your commit comment - - follow the style guide (see below) + - Have a nice, clear, typo-free commit comment. + - If you fixed an issue, refer to it in your commit comment. + - Follow the style guide (see below). -- if you write new code, please add tests and docs for it +- If you write new code, please add tests and docs for it. -- run the tests, fix any issues that come up +- Run the tests, fix any issues that come up. -- make a pull request on GitHub +- Make a pull request on GitHub. -- wait for review by other developers +- Wait for review by other developers. Branching model --------------- @@ -66,10 +66,10 @@ be applied. Changes that are typically considered for backporting: -- Data loss, corruption and inaccessibility fixes -- Security fixes -- Forward-compatibility improvements -- Documentation corrections +- Data loss, corruption and inaccessibility fixes. +- Security fixes. +- Forward-compatibility improvements. +- Documentation corrections. .. rubric:: Maintainer part @@ -311,23 +311,23 @@ Creating a new release Checklist: -- make sure all issues for this milestone are closed or moved to the - next milestone -- check if there are any pending fixes for security issues -- find and fix any low hanging fruit left on the issue tracker -- check that Travis CI is happy -- update ``CHANGES.rst``, based on ``git log $PREVIOUS_RELEASE..`` -- check version number of upcoming release in ``CHANGES.rst`` -- verify that ``MANIFEST.in`` and ``setup.py`` are complete +- Make sure all issues for this milestone are closed or moved to the + next milestone. +- Check if there are any pending fixes for security issues. +- Find and fix any low hanging fruit left on the issue tracker. +- Check that Travis CI is happy. +- Update ``CHANGES.rst``, based on ``git log $PREVIOUS_RELEASE..``. +- Check version number of upcoming release in ``CHANGES.rst``. +- Verify that ``MANIFEST.in`` and ``setup.py`` are complete. - ``python setup.py build_usage ; python setup.py build_man`` and commit (be sure to build with Python 3.5 as Python 3.6 added `more guaranteed hashing algorithms - `_) -- tag the release:: + `_). +- Tag the release:: git tag -s -m "tagged/signed release X.Y.Z" X.Y.Z -- create a clean repo and use it for the following steps:: +- Create a clean repo and use it for the following steps:: git clone borg borg-clean @@ -335,32 +335,32 @@ Checklist: It will also reveal uncommitted required files. Moreover, it makes sure the vagrant machines only get committed files and do a fresh start based on that. -- run tox and/or binary builds on all supported platforms via vagrant, - check for test failures -- create sdist, sign it, upload release to (test) PyPi: +- Run tox and/or binary builds on all supported platforms via vagrant, + check for test failures. +- Create sdist, sign it, upload release to (test) PyPi: :: scripts/sdist-sign X.Y.Z scripts/upload-pypi X.Y.Z test scripts/upload-pypi X.Y.Z -- put binaries into dist/borg-OSNAME and sign them: +- Put binaries into dist/borg-OSNAME and sign them: :: scripts/sign-binaries 201912312359 -- close the release milestone on GitHub -- announce on: +- Close the release milestone on GitHub. +- Announce on: - - Mailing list - - Twitter - - IRC channel (change ``/topic``) + - Mailing list. + - Twitter. + - IRC channel (change ``/topic``). -- create a GitHub release, include: +- Create a GitHub release, include: - * standalone binaries (see above for how to create them) + * Standalone binaries (see above for how to create them). - + for OS X, document the OS X Fuse version in the README of the binaries. + + For OS X, document the OS X Fuse version in the README of the binaries. OS X FUSE uses a kernel extension that needs to be compatible with the code contained in the binary. - * a link to ``CHANGES.rst`` + * A link to ``CHANGES.rst``.