Add the concept of committing windows to README.patches

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



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

1 files changed, 42 insertions, 10 deletions

diff --git a/README.patches b/README.patches
index e2ebb3670..7052b99a4 100644
--- a/README.patches
+++ b/README.patches
@@ -206,10 +206,10 @@ 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 
-   patchset should be reviewed/tested by other developers. So, a new 
+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 
+   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 particulary important for Kernel to userspace ABI changes.
@@ -319,12 +319,12 @@ 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 
-   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-cicle for having a changeset 
-   committed at kernel at the proper time. It also means that the one 
-   changeset should idally address just one issue. So, mixing different 
+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-cicle for having a changeset
+   committed at kernel at the proper time. It also means that the one
+   changeset should idally 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
@@ -363,7 +363,7 @@ 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 a late Acked-by: or a 
+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
@@ -384,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 thenext
+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 proccess (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
    ===================================