From 08f09e417248d98a99e22d68984fe67d20baa6f0 Mon Sep 17 00:00:00 2001 From: Christian Poessinger Date: Sun, 14 Mar 2021 11:29:29 +0100 Subject: 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. --- CONTRIBUTING.md | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) (limited to 'CONTRIBUTING.md') 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 )` 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. -- cgit v1.2.3