Testing is also important:
- - A patch that modifies existing code should be tested with
- `make check` before submission.
+ - A patch that modifies existing code should be tested with `make
+ check` before submission. Please see INSTALL.md, under
+ "Self-Tests", for more information.
- A patch that adds or deletes files should also be tested with
`make distcheck` before submission.
- A patch that modifies Linux kernel code should be at least
build-tested on various Linux kernel versions before
- submission. I suggest versions 2.6.32 and whatever
+ submission. I suggest versions 3.10 and whatever
the current latest release version is at the time.
- A patch that modifies the ofproto or vswitchd code should be
Reported-at: http://openvswitch.org/pipermail/dev/2014-June/040952.html
+ Submitted-at: <URL>
+
+ If a patch was submitted somewhere other than the Open vSwitch
+ development mailing list, such as a GitHub pull request, this header can
+ be used to reference the source.
+
+ Submitted-at: https://github.com/openvswitch/ovs/pull/92
+
VMware-BZ: #1234567
ONF-JIRA: EXT-12345
in old change log entries. (They are obsolete because they do
not tell the reader what bug tracker is referred to.)
+ Fixes: 63bc9fb1c69f (“packets: Reorder CS_* flags to remove gap.”)
+
+ If you would like to record which commit introduced a bug being fixed,
+ you may do that with a “Fixes” header. This assists in determining
+ which OVS releases have the bug, so the patch can be applied to all
+ affected versions. The easiest way to generate the header in the
+ proper format is with this git command:
+
+ git log -1 --pretty=format:"Fixes: %h (\"%s\")" --abbrev=12 COMMIT_REF
+
+ Vulnerability: CVE-2016-2074
+
+ Specifies that the patch fixes or is otherwise related to a
+ security vulnerability with the given CVE identifier. Other
+ identifiers in public vulnerability databases are also
+ suitable.
+
+ If the vulnerability was reported publicly, then it is also
+ appropriate to cite the URL to the report in a Reported-at
+ tag. Use a Reported-by tag to acknowledge the reporters.
+
Developer's Certificate of Origin
---------------------------------
[CodingStyle.md] file describes the coding style used in most of Open
vSwitch. Use Linux kernel coding style for Linux kernel code.
+If your code is non-datapath code, you may use the
+`utilities/checkpatch.py` utility as a quick check for certain commonly
+occuring mistakes (improper leading/trailing whitespace, missing signoffs,
+some improper formatted patch files). For linux datapath code, it is
+a good idea to use the linux script `checkpatch.pl`.
+
Example
-------