diff options
| -rw-r--r-- | README.patches | 35 |
1 files changed, 24 insertions, 11 deletions
diff --git a/README.patches b/README.patches index 2f39f5d52..863415cc8 100644 --- a/README.patches +++ b/README.patches @@ -1,5 +1,5 @@ Mauro Carvalho Chehab <mchehab at infradead dot org> - Updated on 2007 September, 6 + Updated on 2007 December, 1st This file describes the general procedures used by the LinuxTV team (*) and by the v4l-dvb community. @@ -144,7 +144,20 @@ b) All commits at mercurial trees should have a consistent message, From: line shouldn't be omitted, since it will be used for the patch author when converting to -git. -c) For "make commit" to work properly, the HGUSER shell environment var +c) Since June, 1st, 2007, all patches are requested to have their coding style + validated by using script/checkpatch.pl. This check runs automatically by + using "make commit". By default, it will try to use the newest version of + the script, between the kernel one and a copy at v4l-dvb development tree. + + It is always a good idea to use in-kernel version, since additional tests + are performed (like checking for the usage of depreciated API's that are + about to be removed). + + It is possible to override the in-kernel checkpatch.pl location, by using + the CHECKPATCH shell environment var to something like: + CHECKPATCH="/usr/src/linux/scripts/checkpatch.pl" + +d) For "make commit" to work properly, the HGUSER shell environment var should be defined (replacing the names at the left): HGUSER="My Name <myemail@mysite.com>" @@ -171,7 +184,7 @@ c) For "make commit" to work properly, the HGUSER shell environment var It is strongly recommended to have those lines in .bashrc or .profile. -d) All patches shall have a Developers Certificate of Origin +e) All patches shall have a Developers Certificate of Origin version 1.1 in the commit log or the email description, signed by the patch authors, as postulated in the Linux Kernel source at: @@ -194,7 +207,7 @@ d) All patches shall have a Developers Certificate of Origin trees and signed. Otherwise, they may comment on the patch, asking for some review. -e) Although not documented at kernel's Documentation/, a common kernel +f) Although not documented at kernel's Documentation/, a common kernel practice is to use Acked-by: tag. An Acked-by: tag usually means that the acked person didn't write the @@ -206,7 +219,7 @@ e) Although not documented at kernel's Documentation/, a common kernel inserted at master repository. In this case, the ack will be added only at -git tree. -f) Another kernel's practice that is agreed to be good is that a +g) Another kernel's practice that is agreed to be good is that a patchset should be reviewed/tested by other developers. So, a new tag should be used by testers/reviewers. So, reviewers are welcome. After reviewing a patchset, please send an e-mail indicating that, if @@ -214,7 +227,7 @@ f) Another kernel's practice that is agreed to be good is that a Reviewed-by: My Name <myemail@mysite.com> This is particularly important for Kernel to userspace ABI changes. -g) If the patch also affects other parts of kernel (like Alsa +h) If the patch also affects other parts of kernel (like Alsa or i2c), it is required that, when submitting upstream, the patch also goes to the maintainers of that subsystem. To do this, the developer shall copy the interested parties. @@ -237,7 +250,7 @@ g) If the patch also affects other parts of kernel (like Alsa for their acks, then commit to the development tree or send the patch via email with their Acked-by: already included. -h) Sometimes, mainstream changes affect the v4l-dvb tree, and mast be +i) Sometimes, mainstream changes affect the v4l-dvb tree, and mast be backported to the v4l-dvb tree. This kind of commit to the mercurial tree should follow the rules above and should also have the line: @@ -245,7 +258,7 @@ h) Sometimes, mainstream changes affect the v4l-dvb tree, and mast be Patches with this line will not be submitted upstream. -i) Sometimes it is necessary to introduce some testing code inside a +j) Sometimes it is necessary to introduce some testing code inside a module or remove parts that are not yet finished. Also, compatibility tests may be required to provide backporting. @@ -294,7 +307,7 @@ should be included at the See the file v4l/scripts/gentree.pl for a more complete description of what kind of code will be kept and what kind will be removed. -j) To import contributed stuff to a developer's, a script is provided. +k) To import contributed stuff to a developer's, a script is provided. This allows an easy import of mbox-based patch emails. This is done with (called from the root tree directory): @@ -311,7 +324,7 @@ j) To import contributed stuff to a developer's, a script is provided. that can be applied/unapplied for testing. mailimport trusts on it to work, so, this extension should be enabled for mailimport script to work. -k) By submitting a patch to the subsystem maintainer, either via email +l) By submitting a patch to the subsystem maintainer, either via email or via pull request, the patch author(s) are agreeing that the submitted code will be added on Kernel, and that the submitted code are being released as GPLv2. The author may grant additional licenses @@ -319,7 +332,7 @@ k) By submitting a patch to the subsystem maintainer, either via email later. If no specific clause are added, the added code will be assumed as GPLv2 only. -l) "Commit earlier and commit often". This is a common used rule at +m) "Commit earlier and commit often". This is a common used rule at Kernel. This means that a sooner submission of a patch will mean that a review can happen sooner, and help the develop to address the comments. This helps to reduce the life-cycle for having a changeset |