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.
47 The subject line of your email should be in the following format:
48 [PATCH <n>/<m>] <area>: <summary>
50 - [PATCH <n>/<m>] indicates that this is the nth of a series
51 of m patches. It helps reviewers to read patches in the
52 correct order. You may omit this prefix if you are sending
55 - <area>: indicates the area of the Open vSwitch to which the
56 change applies (often the name of a source file or a
57 directory). You may omit it if the change crosses multiple
58 distinct pieces of code.
60 - <summary> briefly describes the change.
62 The subject, minus the [PATCH <n>/<m>] prefix, becomes the first line
63 of the commit's change log message.
68 The body of the email should start with a more thorough description of
69 the change. This becomes the body of the commit message, following
70 the subject. There is no need to duplicate the summary given in the
73 Please limit lines in the description to 79 characters in width.
75 The description should include:
77 - The rationale for the change.
79 - Design description and rationale (but this might be better
80 added as code comments).
82 - Testing that you performed (or testing that should be done
83 but you could not for whatever reason).
87 There is no need to describe what the patch actually changed, if the
88 reader can see it for himself.
90 If the patch refers to a commit already in the Open vSwitch
91 repository, please include both the commit number and the subject of
92 the patch, e.g. 'commit 632d136c (vswitch: Remove restriction on
95 If you, the person sending the patch, did not write the patch
96 yourself, then the very first line of the body should take the form
97 "From: <author name> <author email>", followed by a blank line. This
98 will automatically cause the named author to be credited with
99 authorship in the repository.
104 The description ends with a series of tags, written one to a line as
105 the last paragraph of the email. Each tag indicates some property of
106 the patch in an easily machine-parseable manner.
108 Examples of common tags follow.
110 Signed-off-by: Author Name <author.name@email.address...>
112 Informally, this indicates that Author Name is the author or
113 submitter of a patch and has the authority to submit it under
114 the terms of the license. The formal meaning is to agree to
115 the Developer's Certificate of Origin (see below).
117 If the author and submitter are different, each must sign off.
118 If the patch has more than one author, all must sign off.
120 Signed-off-by: Author Name <author.name@email.address...>
121 Signed-off-by: Submitter Name <submitter.name@email.address...>
123 Co-authored-by: Author Name <author.name@email.address...>
125 Git can only record a single person as the author of a given
126 patch. In the rare event that a patch has multiple authors,
127 one must be given the credit in Git and the others must be
128 credited via Co-authored-by: tags. (All co-authors must also
131 Acked-by: Reviewer Name <reviewer.name@email.address...>
133 Reviewers will often give an Acked-by: tag to code of which
134 they approve. It is polite for the submitter to add the tag
135 before posting the next version of the patch or applying the
136 patch to the repository. Quality reviewing is hard work, so
137 this gives a small amount of credit to the reviewer.
139 Not all reviewers give Acked-by: tags when they provide
140 positive reviews. It's customary only to add tags from
141 reviewers who actually provide them explicitly.
143 Tested-by: Tester Name <reviewer.name@email.address...>
145 When someone tests a patch, it is customary to add a
146 Tested-by: tag indicating that. It's rare for a tester to
147 actually provide the tag; usually the patch submitter makes
148 the tag himself in response to an email indicating successful
151 Reported-by: Reporter Name <reporter.name@email.address...>
153 When a patch fixes a bug reported by some person, please
154 credit the reporter in the commit log in this fashion. Please
155 also add the reporter's name and email address to the list of
156 people who provided helpful bug reports in the AUTHORS file at
157 the top of the source tree.
159 Fairly often, the reporter of a bug also tests the fix.
160 Occasionally one sees a combined "Reported-and-tested-by:" tag
161 used to indicate this. It is also acceptable, and more
162 common, to include both tags separately.
164 (If a bug report is received privately, it might not always be
165 appropriate to publicly credit the reporter. If in doubt,
166 please ask the reporter.)
168 Requested-by: Requester Name <requester.name@email.address...>
169 Suggested-by: Suggester Name <suggester.name@email.address...>
171 When a patch implements a request or a suggestion made by some
172 person, please credit that person in the commit log in this
173 fashion. For a helpful suggestion, please also add the
174 person's name and email address to the list of people who
175 provided suggestions in the AUTHORS file at the top of the
178 (If a suggestion or a request is received privately, it might
179 not always be appropriate to publicly give credit. If in
184 If a patch fixes or is otherwise related to a bug reported in
185 a public bug tracker, please include a reference to the bug in
186 the form of a URL to the specific bug, e.g.:
188 Reported-at: https://bugs.debian.org/743635
190 This is also an appropriate way to refer to bug report emails
191 in public email archives, e.g.:
193 Reported-at: http://openvswitch.org/pipermail/dev/2014-June/040952.html
197 If a patch fixes or is otherwise related to a bug reported in
198 a private bug tracker, you may include some tracking ID for
199 the bug for your own reference. Please include some
200 identifier to make the origin clear, e.g. "VMware-BZ" in this
201 case refers to VMware's internal Bugzilla instance.
206 These are obsolete forms of VMware-BZ: that can still be seen
207 in old change log entries. (They are obsolete because they do
208 not tell the reader what bug tracker is referred to.)
210 Developer's Certificate of Origin
211 ---------------------------------
213 To help track the author of a patch as well as the submission chain,
214 and be clear that the developer has authority to submit a patch for
215 inclusion in openvswitch please sign off your work. The sign off
216 certifies the following:
218 Developer's Certificate of Origin 1.1
220 By making a contribution to this project, I certify that:
222 (a) The contribution was created in whole or in part by me and I
223 have the right to submit it under the open source license
224 indicated in the file; or
226 (b) The contribution is based upon previous work that, to the best
227 of my knowledge, is covered under an appropriate open source
228 license and I have the right under that license to submit that
229 work with modifications, whether created in whole or in part
230 by me, under the same open source license (unless I am
231 permitted to submit under a different license), as indicated
234 (c) The contribution was provided directly to me by some other
235 person who certified (a), (b) or (c) and I have not modified
238 (d) I understand and agree that this project and the contribution
239 are public and that a record of the contribution (including all
240 personal information I submit with it, including my sign-off) is
241 maintained indefinitely and may be redistributed consistent with
242 this project or the open source license(s) involved.
247 If you want to include any comments in your email that should not be
248 part of the commit's change log message, put them after the
249 description, separated by a line that contains just "---". It may be
250 helpful to include a diffstat here for changes that touch multiple
256 The patch should be in the body of the email following the description,
257 separated by a blank line.
259 Patches should be in "diff -up" format. We recommend that you use Git
260 to produce your patches, in which case you should use the -M -C
261 options to "git diff" (or other Git tools) if your patch renames or
262 copies files. Quilt (http://savannah.nongnu.org/projects/quilt) might
263 be useful if you do not want to use Git.
265 Patches should be inline in the email message. Some email clients
266 corrupt white space or wrap lines in patches. There are hints on how
267 to configure many email clients to avoid this problem at:
268 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/email-clients.txt
269 If you cannot convince your email client not to mangle patches, then
270 sending the patch as an attachment is a second choice.
272 Please follow the style used in the code that you are modifying. The
273 CodingStyle file describes the coding style used in most of Open
274 vSwitch. Use Linux kernel coding style for Linux kernel code.
279 From fa29a1c2c17682879e79a21bb0cdd5bbe67fa7c0 Mon Sep 17 00:00:00 2001
280 From: Jesse Gross <jesse@nicira.com>
281 Date: Thu, 8 Dec 2011 13:17:24 -0800
282 Subject: [PATCH] datapath: Alphabetize include/net/ipv6.h compat header.
284 Signed-off-by: Jesse Gross <jesse@nicira.com>
286 datapath/linux/Modules.mk | 2 +-
287 1 files changed, 1 insertions(+), 1 deletions(-)
289 diff --git a/datapath/linux/Modules.mk b/datapath/linux/Modules.mk
290 index fdd952e..f6cb88e 100644
291 --- a/datapath/linux/Modules.mk
292 +++ b/datapath/linux/Modules.mk
293 @@ -56,11 +56,11 @@ openvswitch_headers += \
294 linux/compat/include/net/dst.h \
295 linux/compat/include/net/genetlink.h \
296 linux/compat/include/net/ip.h \
297 + linux/compat/include/net/ipv6.h \
298 linux/compat/include/net/net_namespace.h \
299 linux/compat/include/net/netlink.h \
300 linux/compat/include/net/protocol.h \
301 linux/compat/include/net/route.h \
302 - linux/compat/include/net/ipv6.h \
303 linux/compat/genetlink.inc
305 both_modules += brcompat