1 How to Submit Patches for Open vSwitch
2 ======================================
4 Send changes to Open vSwitch as patches to dev@openvswitch.org.
5 One patch per email, please. More details are included below.
7 If you are using Git, then "git format-patch" takes care of most of
8 the mechanics described below for you.
13 Before you send patches at all, make sure that each patch makes sense.
16 - A given patch should not break anything, even if later
17 patches fix the problems that it causes. The source tree
18 should still build and work after each patch is applied.
19 (This enables "git bisect" to work best.)
21 - A patch should make one logical change. Don't make
22 multiple, logically unconnected changes to disparate
23 subsystems in a single patch.
25 - A patch that adds or removes user-visible features should
26 also update the appropriate user documentation or manpages.
28 Testing is also important:
30 - A patch that adds or deletes files should be tested with
31 "make distcheck" before submission.
33 - A patch that modifies Linux kernel code should be at least
34 build-tested on various Linux kernel versions before
35 submission. I suggest versions 2.6.32 and whatever
36 the current latest release version is at the time.
38 - A patch that modifies the ofproto or vswitchd code should be
39 tested in at least simple cases before submission.
41 - A patch that modifies xenserver code should be tested on
42 XenServer before submission.
44 If you are using GitHub, then you may utilize the travis-ci.org CI build
45 system by linking your GitHub repository to it. This will run some of
46 the above tests automatically when you push changes to your repository.
47 See the "Continuous Integration with Travis-CI" in the INSTALL file for
48 details on how to set it up.
53 The subject line of your email should be in the following format:
54 [PATCH <n>/<m>] <area>: <summary>
56 - [PATCH <n>/<m>] indicates that this is the nth of a series
57 of m patches. It helps reviewers to read patches in the
58 correct order. You may omit this prefix if you are sending
61 - <area>: indicates the area of the Open vSwitch to which the
62 change applies (often the name of a source file or a
63 directory). You may omit it if the change crosses multiple
64 distinct pieces of code.
66 - <summary> briefly describes the change.
68 The subject, minus the [PATCH <n>/<m>] prefix, becomes the first line
69 of the commit's change log message.
74 The body of the email should start with a more thorough description of
75 the change. This becomes the body of the commit message, following
76 the subject. There is no need to duplicate the summary given in the
79 Please limit lines in the description to 79 characters in width.
81 The description should include:
83 - The rationale for the change.
85 - Design description and rationale (but this might be better
86 added as code comments).
88 - Testing that you performed (or testing that should be done
89 but you could not for whatever reason).
93 There is no need to describe what the patch actually changed, if the
94 reader can see it for himself.
96 If the patch refers to a commit already in the Open vSwitch
97 repository, please include both the commit number and the subject of
98 the patch, e.g. 'commit 632d136c (vswitch: Remove restriction on
101 If you, the person sending the patch, did not write the patch
102 yourself, then the very first line of the body should take the form
103 "From: <author name> <author email>", followed by a blank line. This
104 will automatically cause the named author to be credited with
105 authorship in the repository.
110 The description ends with a series of tags, written one to a line as
111 the last paragraph of the email. Each tag indicates some property of
112 the patch in an easily machine-parseable manner.
114 Examples of common tags follow.
116 Signed-off-by: Author Name <author.name@email.address...>
118 Informally, this indicates that Author Name is the author or
119 submitter of a patch and has the authority to submit it under
120 the terms of the license. The formal meaning is to agree to
121 the Developer's Certificate of Origin (see below).
123 If the author and submitter are different, each must sign off.
124 If the patch has more than one author, all must sign off.
126 Signed-off-by: Author Name <author.name@email.address...>
127 Signed-off-by: Submitter Name <submitter.name@email.address...>
129 Co-authored-by: Author Name <author.name@email.address...>
131 Git can only record a single person as the author of a given
132 patch. In the rare event that a patch has multiple authors,
133 one must be given the credit in Git and the others must be
134 credited via Co-authored-by: tags. (All co-authors must also
137 Acked-by: Reviewer Name <reviewer.name@email.address...>
139 Reviewers will often give an Acked-by: tag to code of which
140 they approve. It is polite for the submitter to add the tag
141 before posting the next version of the patch or applying the
142 patch to the repository. Quality reviewing is hard work, so
143 this gives a small amount of credit to the reviewer.
145 Not all reviewers give Acked-by: tags when they provide
146 positive reviews. It's customary only to add tags from
147 reviewers who actually provide them explicitly.
149 Tested-by: Tester Name <reviewer.name@email.address...>
151 When someone tests a patch, it is customary to add a
152 Tested-by: tag indicating that. It's rare for a tester to
153 actually provide the tag; usually the patch submitter makes
154 the tag himself in response to an email indicating successful
157 Reported-by: Reporter Name <reporter.name@email.address...>
159 When a patch fixes a bug reported by some person, please
160 credit the reporter in the commit log in this fashion. Please
161 also add the reporter's name and email address to the list of
162 people who provided helpful bug reports in the AUTHORS file at
163 the top of the source tree.
165 Fairly often, the reporter of a bug also tests the fix.
166 Occasionally one sees a combined "Reported-and-tested-by:" tag
167 used to indicate this. It is also acceptable, and more
168 common, to include both tags separately.
170 (If a bug report is received privately, it might not always be
171 appropriate to publicly credit the reporter. If in doubt,
172 please ask the reporter.)
174 Requested-by: Requester Name <requester.name@email.address...>
175 Suggested-by: Suggester Name <suggester.name@email.address...>
177 When a patch implements a request or a suggestion made by some
178 person, please credit that person in the commit log in this
179 fashion. For a helpful suggestion, please also add the
180 person's name and email address to the list of people who
181 provided suggestions in the AUTHORS file at the top of the
184 (If a suggestion or a request is received privately, it might
185 not always be appropriate to publicly give credit. If in
190 If a patch fixes or is otherwise related to a bug reported in
191 a public bug tracker, please include a reference to the bug in
192 the form of a URL to the specific bug, e.g.:
194 Reported-at: https://bugs.debian.org/743635
196 This is also an appropriate way to refer to bug report emails
197 in public email archives, e.g.:
199 Reported-at: http://openvswitch.org/pipermail/dev/2014-June/040952.html
204 If a patch fixes or is otherwise related to a bug reported in
205 a private bug tracker, you may include some tracking ID for
206 the bug for your own reference. Please include some
207 identifier to make the origin clear, e.g. "VMware-BZ" refers
208 to VMware's internal Bugzilla instance and "ONF-JIRA" refers
209 to the Open Networking Foundation's JIRA bug tracker.
214 These are obsolete forms of VMware-BZ: that can still be seen
215 in old change log entries. (They are obsolete because they do
216 not tell the reader what bug tracker is referred to.)
218 Developer's Certificate of Origin
219 ---------------------------------
221 To help track the author of a patch as well as the submission chain,
222 and be clear that the developer has authority to submit a patch for
223 inclusion in openvswitch please sign off your work. The sign off
224 certifies the following:
226 Developer's Certificate of Origin 1.1
228 By making a contribution to this project, I certify that:
230 (a) The contribution was created in whole or in part by me and I
231 have the right to submit it under the open source license
232 indicated in the file; or
234 (b) The contribution is based upon previous work that, to the best
235 of my knowledge, is covered under an appropriate open source
236 license and I have the right under that license to submit that
237 work with modifications, whether created in whole or in part
238 by me, under the same open source license (unless I am
239 permitted to submit under a different license), as indicated
242 (c) The contribution was provided directly to me by some other
243 person who certified (a), (b) or (c) and I have not modified
246 (d) I understand and agree that this project and the contribution
247 are public and that a record of the contribution (including all
248 personal information I submit with it, including my sign-off) is
249 maintained indefinitely and may be redistributed consistent with
250 this project or the open source license(s) involved.
255 If you want to include any comments in your email that should not be
256 part of the commit's change log message, put them after the
257 description, separated by a line that contains just "---". It may be
258 helpful to include a diffstat here for changes that touch multiple
264 The patch should be in the body of the email following the description,
265 separated by a blank line.
267 Patches should be in "diff -up" format. We recommend that you use Git
268 to produce your patches, in which case you should use the -M -C
269 options to "git diff" (or other Git tools) if your patch renames or
270 copies files. Quilt (http://savannah.nongnu.org/projects/quilt) might
271 be useful if you do not want to use Git.
273 Patches should be inline in the email message. Some email clients
274 corrupt white space or wrap lines in patches. There are hints on how
275 to configure many email clients to avoid this problem at:
276 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/email-clients.txt
277 If you cannot convince your email client not to mangle patches, then
278 sending the patch as an attachment is a second choice.
280 Please follow the style used in the code that you are modifying. The
281 CodingStyle file describes the coding style used in most of Open
282 vSwitch. Use Linux kernel coding style for Linux kernel code.
287 From fa29a1c2c17682879e79a21bb0cdd5bbe67fa7c0 Mon Sep 17 00:00:00 2001
288 From: Jesse Gross <jesse@nicira.com>
289 Date: Thu, 8 Dec 2011 13:17:24 -0800
290 Subject: [PATCH] datapath: Alphabetize include/net/ipv6.h compat header.
292 Signed-off-by: Jesse Gross <jesse@nicira.com>
294 datapath/linux/Modules.mk | 2 +-
295 1 files changed, 1 insertions(+), 1 deletions(-)
297 diff --git a/datapath/linux/Modules.mk b/datapath/linux/Modules.mk
298 index fdd952e..f6cb88e 100644
299 --- a/datapath/linux/Modules.mk
300 +++ b/datapath/linux/Modules.mk
301 @@ -56,11 +56,11 @@ openvswitch_headers += \
302 linux/compat/include/net/dst.h \
303 linux/compat/include/net/genetlink.h \
304 linux/compat/include/net/ip.h \
305 + linux/compat/include/net/ipv6.h \
306 linux/compat/include/net/net_namespace.h \
307 linux/compat/include/net/netlink.h \
308 linux/compat/include/net/protocol.h \
309 linux/compat/include/net/route.h \
310 - linux/compat/include/net/ipv6.h \
311 linux/compat/genetlink.inc
313 both_modules += brcompat