CONTRIBUTING: copy "writing good commit messages" section from docs

To also have an inline reference of the guidlines for fast access, copy the
contents of the "Prepare patch/commit" and "Writing good commit messages" to
out CONTRIBUTING document.

By this you get a fast reference to the guidelines when opening up a
PullRequest.

1 files changed, 75 insertions, 0 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 7ac48ee4c..8458d3208 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -8,6 +8,81 @@ review this contribution guideline.
 
 The following paragraphs are an excerpt from our Documentation.
 
+## Submit a Patch
+
+Patches are always more than welcome. To have a clean and easy to maintain
+repository we have some guidelines when working with Git. A clean repository
+eases the automatic generation of a changelog file.
+
+A good approach for writing commit messages is actually to have a look at the
+file(s) history by invoking git log path/to/file.txt.
+
+### Prepare patch/commit
+
+In a big system, such as VyOS, that is comprised of multiple components, it’s
+impossible to keep track of all the changes and bugs/feature requests in one’s
+head. We use a bugtracker known as Phabricator for it (“issue tracker” would
+be a better term, but this one stuck).
+
+The information is used in three ways:
+
+* Keep track of the progress (what we have already done in this branch and
+  what  we still need to do).
+* Prepare automatic release notes for upcoming releases
+* Help future maintainers of VyOS (it could be you!) to find out why certain
+  things have been changed in the codebase or why certain features have been
+  added
+  
+To make this approach work, every change must be associated with a task number
+(prefixed with **T**) and a component. If there is no bug report/feature
+request for the changes you are going to make, you have to create a Phabricator
+task first. Once there is an entry in Phabricator, you should reference its id
+in your commit message, as shown below:
+
+* `ddclient: T1030: auto create runtime directories`
+* `Jenkins: add current Git commit ID to build description`
+
+If there is no [Phabricator](https://phabricator.vyos.net) reference in the
+commits of your pull request, we have to ask you to amend the commit message.
+Otherwise we will have to reject it.
+
+## Writing good commit messages
+
+The format should be and is inspired by this very good and detailed
+[Git documentation](https://git-scm.com/book/ch5-2.html), it is also worth
+reading https://chris.beams.io/posts/git-commit/.
+
+This is nothing VyOS specific - it is more a general topic for distributed
+development environments.
+
+* A single, short, summary of the commit (recommended 50 characters or less,
+  not exceeding 80 characters) containing a prefix of the changed component
+  and the corresponding Phabricator reference e.g. `snmp: T1111:` or
+  `ethernet: T2222:` - multiple components could be concatenated as in `snmp:
+  ethernet: T3333`
+* In some contexts, the first line is treated as the subject of an email and
+  the rest of the text as the body. The blank line separating the summary from
+  the body is critical (unless you omit the body entirely); tools like rebase
+  can get confused if you run the two together.
+* Followed by a message which describes all the details like:
+  * What/why/how something has been changed, makes everyone’s life easier when
+    working with `git bisect`
+  * All text of the commit message should be wrapped at 72 characters if
+    possible which makes reading commit logs easier with git log on a standard
+	terminal (which happens to be 80x25)
+  * If applicable a reference to a previous commit should be made linking those
+    commits nicely when browsing the history: `After commit abcd12ef ("snmp:
+	this is a headline") a Python import statement is missing, throwing the
+	following exception: ABCDEF`
+* Always use the `-x` option to the `git cherry-pick` command when back or
+  forward porting an individual commit. This automatically appends the line:
+  `(cherry picked from commit <ID>)` to the original authors commit message
+  making it easier when bisecting problems.
+* Every change set must be consistent (self containing)! Do not fix multiple
+  bugs in a single commit. If you already worked on multiple fixes in the same
+  file use git add –patch to only add the parts related to the one issue into
+  your upcoming commit.
+  
 ## Bug Report/Issue
 Issues or bugs are found in any software project. VyOS is not an exception.