Lines Matching +full:simple +full:- +full:framebuffer
19 --------------------------------------------
20 SECTION 1 - CREATING AND SENDING YOUR CHANGE
21 --------------------------------------------
25 1) "diff -up"
26 ------------
28 Use "diff -up" or "diff -uprN" to create patches.
32 in "unified diff" format, as supplied by the '-u' argument to diff(1).
33 Also, please use the '-p' argument which shows which C function each
34 change is in - that makes the resultant diff a lot easier to read.
40 SRCTREE= linux-2.6
47 diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
53 MYSRC= /devel/linux-2.6
55 tar xvfz linux-2.6.12.tar.gz
56 mv linux-2.6.12 linux-2.6.12-vanilla
57 diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
58 linux-2.6.12-vanilla $MYSRC > /tmp/patch
61 the build process, and should be ignored in any diff(1)-generated
67 belong in a patch submission. Make sure to review your patch -after-
80 http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
106 I.e., the patch (series) and its description should be self-contained.
149 5) Select e-mail destination.
153 an assigned maintainer. If so, e-mail that person.
157 linux-kernel@vger.kernel.org. Most kernel developers monitor this
158 e-mail list, and can comment on your changes.
165 Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
166 He gets a lot of e-mail, so typically you should do your best to -avoid-
167 sending him e-mail.
172 usually be sent first to linux-kernel. Only after the patch is
177 6) Select your CC (e-mail carbon copy) list.
179 Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
183 linux-kernel is the primary Linux kernel developer mailing list.
185 USB, framebuffer devices, the VFS, the SCSI subsystem, etc. See the
190 <http://vger.kernel.org/vger-lists.html>
192 If changes affect userland-kernel interfaces, please send
193 the MAN-PAGES maintainer (as listed in the MAINTAINERS file)
194 a man-pages patch, or at least a notification of the change,
211 Non-portable code replaced by portable code (even in arch-specific,
214 in re-transmission mode)
222 developer to be able to "quote" your changes, using standard e-mail
225 For this reason, all patches should be submitting e-mail "inline".
226 WARNING: Be wary of your editor's word-wrap corrupting your patch,
227 if you choose to cut-n-paste your patch.
230 Many popular e-mail applications will not always transmit a MIME
233 decreasing the likelihood of your MIME-attached change being accepted.
236 you to re-send them using MIME.
238 See Documentation/email-clients.txt for hints about configuring
239 your e-mail client so that it sends your patches untouched.
241 8) E-mail size.
247 it is preferred that you store your patch on an Internet-accessible
262 10) Don't get discouraged. Re-submit.
277 * Your patch was not sufficiently discussed on linux-kernel.
279 * An e-mail formatting issue (re-read this section).
281 * He gets tons of e-mail, and yours got lost in the shuffle.
284 When in doubt, solicit comments on linux-kernel mailing list.
290 Due to high e-mail traffic to Linus, and to linux-kernel, it is common
293 e-mail discussions.
301 layers of maintainers, we've introduced a "sign-off" procedure on
304 The sign-off is a simple line at the end of the explanation for the
306 pass it on as an open-source patch. The rules are pretty simple: if you
331 personal information I submit with it, including my sign-off) is
337 Signed-off-by: Random J Developer <random@developer.example.org>
343 point out some special detail about the sign-off.
349 counter-productive waste of time and energy. Rule (b) allows you to adjust
352 you add a line between the last Signed-off-by header and yours, indicating
356 you are responsible for last-minute changes. Example :
358 Signed-off-by: Random J Developer <random@developer.example.org>
360 Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
368 Special note to back-porters: It seems to be a common and useful practise
371 here's what we see in 2.6-stable :
388 tracking your trees, and to people trying to trouble-shoot bugs in your
392 13) When to use Acked-by: and Cc:
394 The Signed-off-by: tag indicates that the signer was involved in the
399 arrange to have an Acked-by: line added to the patch's changelog.
401 Acked-by: is often used by the maintainer of the affected code when that
404 Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
407 into an Acked-by:.
409 Acked-by: does not necessarily indicate acknowledgement of the entire patch.
410 For example, if a patch affects multiple subsystems and has an Acked-by: from
423 14) Using Reported-by:, Tested-by: and Reviewed-by:
426 Reported-by: tag to credit the reporter for their contribution. Please
432 A Tested-by: tag indicates that the patch has been successfully tested (in
437 Reviewed-by:, instead, indicates that the patch has been reviewed and found
442 By offering my Reviewed-by: tag, I state that:
462 A Reviewed-by tag is a statement of opinion that the patch is an
465 offer a Reviewed-by tag for a patch. This tag serves to give credit to
467 done on the patch. Reviewed-by: tags, when supplied by reviewers known to
480 - A "from" line specifying the patch author.
482 - An empty line.
484 - The body of the explanation, which will be copied to the
487 - The "Signed-off-by:" lines, described above, which will
490 - A marker line containing simply "---".
492 - Any additional comments not suitable for the changelog.
494 - The actual patch (diff output).
497 alphabetically by subject line - pretty much any email reader will
498 support that - since because the sequence number is zero-padded,
511 globally-unique identifier for that patch. It propagates all the way
518 --oneline".
520 For these reasons, the "summary" must be no more than 70-75
523 succinct and descriptive, but that is what a well-written summary
565 The "---" marker line serves the essential purpose of marking for patch
568 One good use for the additional comments after the "---" marker is for
577 If you are going to include a diffstat after the "---" marker, please
578 use diffstat options "-p 1 -w 70" so that filenames are listed from
590 that a triple-click just selects the whole thing.
596 git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
600 so that I don't have to hunt-and-peck for the address and inevitably
604 thing to pull, and double-check that I have the right branch-name).
607 Please use "git diff -M --stat --summary" to generate the diffstat:
608 the -M enables rename detection, and the summary enables a summary of
614 -----------------------------------
615 SECTION 2 - HINTS, TIPS, AND TRICKS
616 -----------------------------------
631 another -- in this case you should not modify the moved code at all in
643 - ERROR: things that are very likely to be wrong
644 - WARNING: things requiring careful review
645 - CHECK: things requiring thought
657 Let the compiler optimize away the "no-op" case.
659 Simple example, of poor code:
663 return -ENODEV;
668 Cleaned-up example:
678 return -ENODEV;
692 string-izing].
699 4) Don't over-design.
702 be useful: "Make it as simple as you can, and no simpler."
706 ----------------------
707 SECTION 3 - REFERENCES
708 ----------------------
714 <http://linux.yyz.us/patch-format.html>
716 Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
718 <http://www.kroah.com/log/linux/maintainer-02.html>
719 <http://www.kroah.com/log/linux/maintainer-03.html>
720 <http://www.kroah.com/log/linux/maintainer-04.html>
721 <http://www.kroah.com/log/linux/maintainer-05.html>
723 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
724 <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
734 http://halobates.de/on-submitting-patches.pdf
736 --