merge: http://linuxtv.org/hg/~mkrufky/fusionhdtv

From: Mauro Carvalho Chehab <mchehab@infradead.org>



Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>

1 files changed, 60 insertions, 12 deletions

diff --git a/README.patches b/README.patches
index ea69fd2c0..2f39f5d52 100644
--- a/README.patches
+++ b/README.patches
@@ -1,5 +1,5 @@
 Mauro Carvalho Chehab <mchehab at infradead dot org>
-					Updated on 2007 August, 1st
+					Updated on 2007 September, 6
 
 This file describes the general procedures used by the LinuxTV team (*)
 and by the v4l-dvb community.
@@ -206,7 +206,15 @@ 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)  If the patch also affects other parts of kernel (like Alsa
+f) 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
+   possible, with some additional data about the testing, with the tag:
+	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
     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.
@@ -229,7 +237,7 @@ f)  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.
 
-g) Sometimes, mainstream changes affect the v4l-dvb tree, and mast be
+h) 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:
 
@@ -237,7 +245,7 @@ g) Sometimes, mainstream changes affect the v4l-dvb tree, and mast be
 
    Patches with this line will not be submitted upstream.
 
-h) Sometimes it is necessary to introduce some testing code inside a
+i) 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.
 
@@ -286,7 +294,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.
 
-i) To import contributed stuff to a developer's, a script is provided.
+j) 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):
 
@@ -303,7 +311,7 @@ i) 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.
 
-j) By submitting a patch to the subsystem maintainer, either via email
+k) 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
@@ -311,6 +319,14 @@ j) 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
+   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
+   committed at kernel at the proper time. It also means that the one
+   changeset should ideally address just one issue. So, mixing different
+   things at the same patch should be avoided.
+
 5. Knowing about newer patches committed at master hg repository
    =============================================================
 
@@ -347,8 +363,8 @@ There's a delay between updating a patch at master and sending it to
 mainstream. During this period, it is possible to review a patch. The
 common situations are:
 
-1) If a patch at master tree receives an Acked-by:, this can be added at
--git tree;
+1) If a patch at master tree receives a late Acked-by: or a
+Reviewed-by:, this can be added at -git tree;
 
 2) If somebody fully nacks a patch applied at -hg, A reverse patch
 can be applied at -hg, and the original patch can be removed -git;
@@ -368,6 +384,38 @@ to do a diff between the kernel tree and v4l-dvb mercurial tree
 backport patch from mainstream to v4l-dvb is generally applied by the
 maintainer.
 
+8. Commit windows
+   ==============
+
+Kernel development occurs on some cycles, according with the following
+picture:
+
+------------   2 week    ------------     ---------------     ---------
+| 2.6.(x-1) | ---------> | 2.6.x-rc1 | .. | 2.6.x-rc[n] | --> | 2.6.x |
+------------             ------------     ---------------     ---------
+	      Submission
+		Window
+
+Once a kernel release is done (for example, 2.6.(x-1) version), a
+submission window for the newer features and board additions to the next
+kernel release should start. This means that the subsystem maintainer
+will use this window to submit the work that were done during 2.6.(x-2)
+time.
+
+For this to happen, patches for 2.6.x should be already at the subsystem
+maintainers -hg tree before the release of 2.6.(x-1), to allow proper
+testing.
+
+After the submission window, only patches with bug fixes should be sent
+to mainstream. This means that the subsystem maintainer will separate
+those patches from the submitted ones for kernel submission during -rc
+cycle. Generally, the stabilization process (rc kernels) takes from 5
+to 7 weeks.
+
+To make life easier for the subsystem maintainer, please add:
+[FIX] at the subject of the submitted emails or at the commit first
+lines.
+
 7. Patch submission from the community
    ===================================
 
@@ -516,8 +564,8 @@ g. If it is a newer driver (not yet in one of the development trees),
    recommended way is not to create a newer directory, but keep the
    driver into an existing one.
 
-   Assumming that the will be V4L+DVB, the better place for it to be is under
-   /linux/drivers/media/video. Assumming also that the newer driver
+   Assuming that the will be V4L+DVB, the better place for it to be is under
+   /linux/drivers/media/video. Assuming also that the newer driver
    will be called as "newdevice", you need to do:
 
    a) add at /linux/drivers/media/video/Kconfig something like:
@@ -543,7 +591,7 @@ EXTRA_CFLAGS = -Idrivers/media/video
    codes. Ideally, a source file should have up to 1000 source code
    lines. After that, you should consider splitting it into smaller files.
 
-   In this case, assumming that the will be V4L+DVB, and that the driver
+   In this case, assuming that the will be V4L+DVB, and that the driver
    is called "newdevice", all that is needed to add the newer driver is:
 
    a) create a newer dir with your driver, for example:
@@ -574,7 +622,7 @@ obj-$(CONFIG_VIDEO_NEWDEVICE) += newdevice/
 
 source "drivers/media/video/newdevice/Kconfig"
 
-   After that, you will be able to use v4l-dvb makefile to compile your
+   After that, you will be able to use v4l-dvb Makefile to compile your
    driver.  With:
 
 	make help