From 858685883b478121d9d72779c6a691f62d8da3ac Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 6 Sep 2007 12:09:00 +0100 Subject: Add the newer reviewed-by: tag, as agreed to be used at KS/2007 From: Mauro Carvalho Chehab At kernel summit, it were requested that subsystem maintainers should push for having more reviewing at the kernel submitted code, to avoid regressions and bugs. Those changes reflects this direction. More can be read at: http://lwn.net/Articles/248388/ Signed-off-by: Mauro Carvalho Chehab --- README.patches | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) (limited to 'README.patches') diff --git a/README.patches b/README.patches index ea69fd2c0..90ae313d8 100644 --- a/README.patches +++ b/README.patches @@ -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 + This is particulary 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 @@ -347,8 +355,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; -- cgit v1.2.3 From 8d6f1ae6d289254a97015ac9629d831f06c9966a Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 6 Sep 2007 12:13:11 +0100 Subject: Add the "commit earlier, commit often concept" From: Mauro Carvalho Chehab Signed-off-by: Mauro Carvalho Chehab --- README.patches | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'README.patches') diff --git a/README.patches b/README.patches index 90ae313d8..e2ebb3670 100644 --- a/README.patches +++ b/README.patches @@ -319,6 +319,14 @@ 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 + things at the same patch should be avoided. + 5. Knowing about newer patches committed at master hg repository ============================================================= -- cgit v1.2.3 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 From 6b59fbe5fa40581818289f66c6337c300056bda8 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 6 Sep 2007 12:42:15 +0100 Subject: Updates timestamp and fix english bad words. From: Mauro Carvalho Chehab Signed-off-by: Mauro Carvalho Chehab --- README.patches | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'README.patches') diff --git a/README.patches b/README.patches index 7052b99a4..2f39f5d52 100644 --- a/README.patches +++ b/README.patches @@ -1,5 +1,5 @@ Mauro Carvalho Chehab - 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. @@ -212,7 +212,7 @@ f) Another kernel's practice that is agreed to be good is that a 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. + 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 @@ -322,9 +322,9 @@ k) By submitting a patch to the subsystem maintainer, either via email 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 + 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 idally address just one issue. So, mixing different + 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 @@ -397,7 +397,7 @@ picture: 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 +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. @@ -409,7 +409,7 @@ 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 +cycle. Generally, the stabilization process (rc kernels) takes from 5 to 7 weeks. To make life easier for the subsystem maintainer, please add: @@ -564,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: @@ -591,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: @@ -622,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 -- cgit v1.2.3