From 3ed5240a7306a01c50c1c3917a83fcf155739852 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 6 Sep 2007 12:30:52 +0100 Subject: Add the concept of committing windows to README.patches From: Mauro Carvalho Chehab Signed-off-by: Mauro Carvalho Chehab --- README.patches | 52 ++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 42 insertions(+), 10 deletions(-) (limited to 'README.patches') 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 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 =================================== -- cgit v1.2.3