v4l2: add note on testing the spec when modifying videodev2.h

From: Hans Verkuil <hverkuil@xs4all.nl>

Priority: normal

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>

1 files changed, 29 insertions, 24 deletions

diff --git a/README.patches b/README.patches
index 931c15960..28d697302 100644
--- a/README.patches
+++ b/README.patches
@@ -1,5 +1,5 @@
 Mauro Carvalho Chehab <mchehab at infradead dot org>
-					Updated on 2009 January 8
+					Updated on 2009 February 9
 
 This file describes the general procedures used by the LinuxTV team (*)
 and by the v4l-dvb community.
@@ -255,30 +255,35 @@ g) 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.
 
-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.
+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.
 
-    At mercurial tree, this can be handled automatically by the LinuxTV
-    scripts, by using the cc: meta tag, together with the Signed-off-by
-    lines. Something like:
+   At mercurial tree, this can be handled automatically by the LinuxTV
+   scripts, by using the cc: meta tag, together with the Signed-off-by
+   lines. Something like:
 
 	CC: someotherkerneldeveloper@someplace
 	Signed-off-by: nowhere <nowhere@noplace.org>
 
-    This way, when a patch arrives mercurial hg tree, a mailbomb script
-    will copy the proper interested parties.
+   This way, when a patch arrives mercurial hg tree, a mailbomb script
+   will copy the proper interested parties.
 
-    When submitting a patch via e-mail, it is better to copy all interested
-    parties directly, by adding them as cc's to the email itself.
+   When submitting a patch via e-mail, it is better to copy all interested
+   parties directly, by adding them as cc's to the email itself.
 
-    Please note that those changes generally require ack from the
-    other subsystem maintainers. So, the best practice is to first ask
-    for their acks, then commit to the development tree or send the
-    patch via email with their Acked-by: already included.
+   Please note that those changes generally require ack from the
+   other subsystem maintainers. So, the best practice is to first ask
+   for their acks, then commit to the development tree or send the
+   patch via email with their Acked-by: already included.
 
-i) Sometimes, mainstream changes affect the v4l-dvb tree, and mast be
+i) If the patch modifies the include/linux/videodev2.h file, then you
+   must also run 'make spec' to verify that the V4L2 specification
+   document still builds. Of course, any changes you make to the public
+   V4L2 API must be documented anyway.
+
+j) 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:
 
@@ -286,7 +291,7 @@ i) Sometimes, mainstream changes affect the v4l-dvb tree, and mast be
 
    Patches with this line will not be submitted upstream.
 
-j) Sometimes it is necessary to introduce some testing code inside a
+k) 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.
 
@@ -319,8 +324,8 @@ j) Sometimes it is necessary to introduce some testing code inside a
 
 	#include "mydriver-header.h"
 
-should be included at the
-   files under v4l-dvb tree. This header also includes linux/version.h.
+   should be included at the files under v4l-dvb tree. This header also
+   includes linux/version.h.
 
    To include testing code, #if 0 or #if 1 may be used. If this code
    is meant to go also to kernel, a comment with the word "keep" should
@@ -337,7 +342,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.
 
-k) To import contributed stuff to a developer's, a script is provided.
+l) 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):
 
@@ -354,7 +359,7 @@ k) 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.
 
-l) By submitting a patch to the subsystem maintainer, either via email
+m) 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
@@ -362,7 +367,7 @@ l) 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.
 
-m) "Commit earlier and commit often". This is a common used rule at
+n) "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
@@ -370,7 +375,7 @@ m) "Commit earlier and commit often". This is a common used rule at
    changeset should ideally address just one issue. So, mixing different
    things at the same patch should be avoided.
 
-n) Sometimes, the maintainer may need to slightly modify patches you receive
+o) Sometimes, the maintainer may need to slightly modify patches you receive
    in order to merge them, because the code is not exactly the same in your
    tree and the submitters'. In order to save time, it may do the changes and
    add a line before his SOB, as stated on Documentation/SubmittingPatches,