Expand the CODING_STYLE with an explanation of commit requirements
authorPeter Hutterer <peter.hutterer@who-t.net>
Wed, 4 Dec 2019 22:16:09 +0000 (08:16 +1000)
committerPeter Hutterer <peter.hutterer@who-t.net>
Thu, 5 Dec 2019 00:40:37 +0000 (10:40 +1000)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
CODING_STYLE.md

index 4fe97ed79d3e812b13bee85f0a8fc3e094e96b4a..02e58446298fc053beb3eb50e6606ffc52583f5a 100644 (file)
@@ -1,3 +1,4 @@
+# Coding style
 
 - Indentation in tabs, 8 characters wide, spaces after the tabs where
   vertical alignment is required (see below)
@@ -133,3 +134,94 @@ if (foo) {
 
 - Use stdbool.h's bool for booleans within the library (instead of `int`).
   Exception: the public API uses int, not bool.
+
+# Git commit message requirements
+
+Our CI will check the commit messages for a few requirements. Below is the
+list of what we expect from a git commit.
+
+## Commit message content
+
+A [good commit message](http://who-t.blogspot.com/2009/12/on-commit-messages.html) needs to
+answer three questions:
+
+- Why is it necessary? It may fix a bug, it may add a feature, it may
+  improve performance, reliabilty, stability, or just be a change for the
+  sake of correctness.
+- How does it address the issue? For short obvious patches this part can be
+  omitted, but it should be a high level description of what the approach
+  was.
+- What effects does the patch have? (In addition to the obvious ones, this
+  may include benchmarks, side effects, etc.)
+
+These three questions establish the context for the actual code changes, put
+reviewers and others into the frame of mind to look at the diff and check if
+the approach chosen was correct. A good commit message also helps
+maintainers to decide if a given patch is suitable for stable branches or
+inclusion in a distribution.
+
+## Developer Certificate of Origin
+
+Your commit **must** be signed off with a line:
+```
+Signed-off-by: <your name> <your email address>
+```
+By signing off, you indicate the [developer certificate of origin](https://developercertificate.org/).
+
+> By making a contribution to this project, I certify that:
+>
+> (a) The contribution was created in whole or in part by me and I
+>     have the right to submit it under the open source license
+>     indicated in the file; or
+>
+> (b) The contribution is based upon previous work that, to the best
+>     of my knowledge, is covered under an appropriate open source
+>     license and I have the right under that license to submit that
+>     work with modifications, whether created in whole or in part
+>     by me, under the same open source license (unless I am
+>     permitted to submit under a different license), as indicated
+>     in the file; or
+>
+> (c) The contribution was provided directly to me by some other
+>     person who certified (a), (b) or (c) and I have not modified
+>     it.
+>
+> (d) I understand and agree that this project and the contribution
+>     are public and that a record of the contribution (including all
+>     personal information I submit with it, including my sign-off) is
+>     maintained indefinitely and may be redistributed consistent with
+>     this project or the open source license(s) involved.
+
+## Commit message format
+
+The canonical git commit message format is:
+
+```
+one line as the subject line with a high-level note
+
+full explanation of the patch follows after an empty line. This explanation
+can be multiple paragraphs and is largely free-form. Markdown is not
+supported.
+
+You can include extra data where required like:
+- benchmark one says 10s
+- benchmark two says 12s
+
+Signed-off-by: <your name> <your email>
+```
+
+The subject line is the first thing everyone sees about this commit, so make
+sure it's on point.
+
+## Commit message technical requirements
+
+- The commit message should use present tense (not past tense). Do write
+  "change foo to bar", not "changed foo to bar".
+- The text width of the commit should be 78 chars or less, especially the
+  subject line.
+- The author and signed-off-by must be your real name and email address. We
+  do not accept the default `@users.noreply` gitlab addresses.
+  ```
+  git config --global user.name Your Name
+  git config --global user.email your@email
+  ```