[BlueZ v2 6/7] doc: Port maintainer-guidelines.txt to RST

[Bastien Nocera <hadess@hadess.net>]

---
 ...idelines.txt => maintainer-guidelines.rst} | 61 +++++++++++--------
 1 file changed, 35 insertions(+), 26 deletions(-)
 rename doc/{maintainer-guidelines.txt => maintainer-guidelines.rst} (65%)

diff --git a/doc/maintainer-guidelines.txt b/doc/maintainer-guidelines.rst
similarity index 65%
rename from doc/maintainer-guidelines.txt
rename to doc/maintainer-guidelines.rst
index b875f008258b..a6e756b81c51 100644
--- a/doc/maintainer-guidelines.txt
+++ b/doc/maintainer-guidelines.rst
@@ -1,25 +1,28 @@
+=====================
 Maintainer guidelines
-*********************
+=====================
 
 This document is intended for the maintainers of the BlueZ project. It
 serves as basic guidelines for handling patch review and commit access.
 
 
 Rule 1: Keep the GIT tree clean and linear
-==========================================
+------------------------------------------
 
-The bluetooth.git, bluetooth-next.git and bluez.git trees are not your
+The ``bluetooth.git``, ``bluetooth-next.git`` and ``bluez.git`` trees are not your
 private playground. The history is meant to be clean and linear.
 
-	- NO merges
-	- NO branches
-	- NO tags
+- NO merges
+- NO branches
+- NO tags
 
 If anyone needs testing or work on a feature, clone the tree and do
 it in your own copy. The master trees are off limits.
 
 One advise to avoid any accidental errors in this area to set proper
-options in global ~/.gitconfig or local .git/config files.
+options in global ``~/.gitconfig`` or local ``.git/config`` files.
+
+.. code-block::
 
 	[merge]
 		ff = only
@@ -29,7 +32,7 @@ in doubt ask one of the seasoned maintainers.
 
 
 Rule 2: Enforce clean commit messages
-=====================================
+-------------------------------------
 
 The commit messages are required to be clean and follow style guidelines
 to be consistent.
@@ -45,20 +48,22 @@ job to ensure we get proper firstname lastname <email> authorship.
 
 It is also important that the committer itself uses a valid name and
 email address when committing patches. So ensure that either the
-global ~/.gitconfig or local .git/config provides proper values.
+global ``~/.gitconfig`` or local ``.git/config`` provides proper values.
+
+.. code-block::
 
 	[user]
 		name = Peter Mustermann
 		email = peter@mustermann.de
 
-Commit messages for bluez.git shall not contain Signed-off-by
+Commit messages for ``bluez.git`` shall not contain ``Signed-off-by``
 signatures. They are not used in userspace and with that it is the
 maintainers job to ensure they do not get committed to the repository.
 
-For bluetooth.git and bluetooth-next.git The Signed-off-by process is
-used and the signatures are required.
+For ``bluetooth.git`` and ``bluetooth-next.git``, the ``Signed-off-by``
+process is used and the signatures are required.
 
-Tags like Change-Id generated from Gerrit are never acceptable. It is
+Tags like ``Change-Id`` generated from Gerrit are never acceptable. It is
 the maintainers job to ensure that these are not committed into the
 repositories.
 
@@ -67,48 +72,52 @@ reversed. If in doubt ask one of the seasoned maintainers.
 
 
 Rule 3: Enforce correct coding style
-====================================
+------------------------------------
 
 The coding style follows roughly the kernel coding style with any
-exceptions documented in doc/coding-style.txt.
+exceptions documented in :doc:`coding-style <coding-style>`.
 
 To ensure trivial white-space errors don't get committed, have the
-following in your .gitconfig:
+following in your ``.gitconfig``:
+
+.. code-block::
 
 	[apply]
 		whitespace = error
 
 It can also be helpful to use the checkpatch.pl script coming with the
 Linux kernel to do some automated checking. Adding the following to your
-.git/hooks/pre-commit and .git/hooks/pre-applypatch is a simple way to
+``.git/hooks/pre-commit`` and ``.git/hooks/pre-applypatch`` is a simple way to
 do this:
 
+.. code-block::
 	exec git diff --cached | ~/src/linux/scripts/checkpatch.pl -q \
 		--no-tree --no-signoff --show-types \
 		--ignore CAMELCASE,NEW_TYPEDEFS,INITIALISED_STATIC -
 
-The above assumes that a kernel tree resides in ~/src/linux/.
+The above assumes that a kernel tree resides in ``~/src/linux/``.
 
 
 Rule 4: Pay extra attention to adding new files to the tree
-===========================================================
+-----------------------------------------------------------
 
 New files that are added to the tree require several things to be
 verified first:
 
-	- Check that the names are acceptable with other maintainers
-	- Ensure that the file modes are correct
-	- Verify that the license & copyright headers are correct
-	- If the file is supposed to be part of the release tarball,
-	  make sure that it gets picked up by 'make dist' (particularly
-	  important for documentation or other files that are not code)
+- Check that the names are acceptable with other maintainers
+- Ensure that the file modes are correct
+- Verify that the license & copyright headers are correct
+- If the file is supposed to be part of the release tarball,
+  make sure that it gets picked up by 'make dist' (particularly
+  important for documentation or other files that are not code)
 
 
 Rule 5: Keep the mailing list in sync with the commit process
-=============================================================
+-------------------------------------------------------------
 
 When applying patches, be sure to send a response to the mailing list as
 soon as the code has been pushed to the upstream tree. Usually this
 means one email per patch, however patch-sets may only have one response
 covering the entire set. If applying a subset of a patch-set clearly
 state what was applied in your response.
+
-- 
2.52.0