[linux-dvb] [RFC] Reviewed development procedures
CityK
CityK at rogers.com
Wed Mar 7 22:12:10 CET 2007
Hi Mauro,
Here are my suggestions:
Mauro Carvalho Chehab wrote:
> diff -r f71d56dfeb0d README.patches
> --- a/README.patches Wed Mar 07 12:28:33 2007 -0200
> +++ b/README.patches Wed Mar 07 16:44:05 2007 -0200
> @@ -1,58 +1,375 @@ Mauro Carvalho Chehab 2005 Dec 02
> -Mauro Carvalho Chehab 2005 Dec 02
> -
> - The master copy of the video4linux and dvb kernel subsystem is now
> -maintained jointly at http://linuxtv.org/
> -
> -=== v4l-dvb snapshots available at linuxtv.org
> -
> - We are now publishing periodic snapshots (about once a month or
> -before rellevant changes) at linuxtv.org. The main idea is to have
>
^ relevant
> -"stable" snapshots on Linuxtv. You can check it at:
>
^ the snapshot at
> -
> -http://linuxtv.org/downloads/snapshots
> -
> -=== v4l-dvb quilt available at linuxtv.org
> -
> - It is also available patches against latest development kernel at:
>
^ what is "it" .............................^
as......................^the..................................... use a
colon, remove at
> -http://linuxtv.org/downloads/quilt
> -
> - patches/series shows the correct order to apply.
> -
> -== Getting the latest Snapshot
> -
> - You must have mercurial installed in order to access the
>
^Mercurial (Hg)
> -repository. To get the latest sources from Hg you need to issue the
>
^ v4l-dvb
> -following command:
> -
> -hg clone http://linuxtv.org/hg/v4l-dvb
> -
> -* Patches should be built against v4l-dvb master Hg repository.
>
^ the
> -
> -=== How to get your changes into the mainline tree?
> -
> -1. Post your patches to the corresponding mailing list for review and
> -testing by other people. For analog or core changes, the mailing list is
> -video4linux-list at redhat.com. For DVB changes, the mailing list
> -is linux-dvb at linuxtv.org. The latest requires subscription.
>
^ the latest
"what", or did you mean "later"?
> -http://linuxtv.org/lists.php
> -
> -2. Using [PATCH] at subject will help maintainers to better handle it.
>
^in the message subject header/line
will assist maintainers with its handling.
> -
> -3. Please include a ChangeLog description in the headers of your patch.
> -
> -4. Every patch shall have a Developers Certificate of Origin like
> -
> -Signed-off-by: Your name <name at yoursite.com>
> -
> -with name of people envolving on making it.
>
^ the names of the persons involved with the patches creation
> -
> - This should be a real name and address. The exact meaning of the
> -signed-off-by is postulated at linux source code, at file:
>
^in
? ^in ?
> +Mauro Carvalho Chehab <mchehab at infradead dot org>
> +2007 Mar 6
> +
> +This file describes the general procedures used by the LinuxTV team (*)
> +and by the v4l-dvb community.
> +
> +(*) This is just an aka for the main developers involved in V4L/DVB
>
^ FYI ? (aka is short for also
known as ... which doesn't make sense in the context of the sentence)
Maybe: "This is just an FYI in regards to the main developers...."
> +drivers. They are a volunteer and unremunerated group of people that
> +have the common interest of providing a good support on Linux for
>
^remove "a good" , maybe "the best support on Linux for ....
> +receiving and capturing video streams from Webcams, Analog TV, Digital
>
^the reception and capturing of ....
> +TV and radio broadcast AM/FM.
>
^ sources.
> +
> +1. A Brief introduction about patch management
> + ==========================================
> +
> +Current V4L/DVB development is based on a modern SCM system that
> +fits better into kernel development model, called Mercurial (aka hg).
> +
> +Kernel development model is based on a similar SCM, called git. While
> +very powerful for distributed development, git usage is not simple for
> +final users. That's the reason why hg was selected for V4L/DVB
> +development.
>
How about something along the lines of:
The Linux kernel development model is based upon a modern SCM system
known as git. While git is a very powerful model for distributed
development, its usage, however, is not simple or suited for final/end
users. For this reason alone, the LinuxTV project has currently chosen
to employ the Mercurial (aka Hg) SCM system for V4L/DVB development. Hg
is a modern SCM and works complementry to the similar git development
model used by the kernel.
> +
> +There are some tutorials, FAQs and other valuable informations at
> +http://selenic.com/mercurial about hg usage.
> +
> +Mercurial is a distributed SCM, which means every developer gets his
^ remove his, use their
>
> +own full copy of the repository (including the complete revision
> +history), and can work and commit locally without network connection.
> +The resulting changesets can then be exchanged between repositories and
>
^ change-sets ?
> +finally published to the master repository in linuxtv.org. A list of
> +current available repositories is available at: http://linuxtv.org/hg
> +
> +2. Git trees' relationships with v4l/dvb development
> + =================================================
> +
> +The main kernel trees are hosted at http://git.kernel.org. Each tree
> +is owned by a maintainer.
> +
> +The main kernel tree is owned by Linus Torvalds, being located at:
> + http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
> +
> +The subsystem master tree is owned by the subsystem maintainer (Mauro
> +Carvalho Chehab) being located at:
> + http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git
> +
> +Michael Krufky maintains a number of backport trees, which have patches
> +contained at the subsystem master tree that are needed to fix some known
> +issues on previous kernel versions, also at
> + http://git.kernel.org/http://git.kernel.org/?p=linux/kernel/git/mkrufky/v4l-dvb-2.6.x.y.git
> +
> +3. Mercurial trees used for v4l/dvb development
> + ============================================
> +
> +V4L/DVB driver development is hosted at http://linuxtv.org. There are a
> +number of trees there each owned by a developer of the LinuxTV team.
>
^There are a number of development trees found there, each owned
by a ....
> +
> +There is also a master mercurial repository, owned by the subsystem
> +maintainer, available at:
> + http://linuxtv.org/hg/v4l-dvb
> +
> +When a developer believes that he has patches done to be merged, he
>
^ remove done
> +sends a request tthe developers' mailing list and to the subsystem
>
^the
> +maintainer. The patches are analized and, if they look ok, merged into
>
^ analyzed or
analysed ^ seem sane ?
> +the master repository.
> +
> +It is good practice that each developer will have at least one tree
> +called 'v4l-dvb', which keeps their patches, and periodically update
>
^they
> +this tree with the master tree's patches.
> +
> +4. Community best practices
> + ========================
> +
> +From accumulated experience, there are some basic rules that should
> +be followed by the community:
> +
> +a) Every developer should follow the "rules of thumb" of kernel development
> + stated at Linux source code, especially those stated at kernel,
> + under:
> + Documentation/HOWTO
> Documentation/SubmittingPatches
> -
> -5. Fix problems and repeat until everyone is happy ;)
> -
> -6. Maintainers will periodically submit changes to mainstream.
> -
> -Mauro
> -Mauro Carvalho Chehab <mchehab .at. linuxtv .dot. org>
> + Documentation/SubmittingDrivers
> + Documentation/SubmitChecklist
> + Documentation/CodingStyle
> +
> +b) All commits at mercurial trees should have a consistent message,
> + describing the patch. This is done by using:
> +
> + make commit
> +
> + This will run some scripts that check changed files, correct
> + bad whitespace and prepare the last Signed-off-by: field, as
> + described below. A good comment will have a brief
> + description at the first line, up to 68 characters wide, a blank
> + line, the patch author's name on the third line, a blank line, and
> + then a brief description, with no more than 80 chars per line, e. g.:
> +
> + This patch does nothing
> +
> + From: nowere <nowere at noplace.org>
> +
> + This is just a sample commit comment, just for reference purposes.
> +
> + This "patch" does nothing.
> +
> + Signed-off-by: nowere <nowere at noplace.org>
> +
> + All lines starting with # and all lines starting with HG: will be
> + removed from the mercurial commit log.
> +
> + *WARNING* Be careful not to leave the first line blank, otherwise hg
> + will leave subject blank.
> +
> + From: line shouldn't be ommited, since it will be used for the
> + patch author when converting to -git.
> +
> +c) For "make commit" to work properly, the HGUSER shell environment var
> + should be defined (replacing the names at the left):
> +
> + HGUSER="My Name <myemail at mysite.com>"
> +
> + If HGUSER is not set, then, if present, the username defined in the
> + user's ~/.hgrc file will be used. Use of the .hgrc file is preferred
> + over the HGUSER variable according to the hg man page.
> +
> + This name will be used for both the user metadata in the Hg commit
> + log and the initial values of the "From:" and "Signed-off-by:" lines
> + in the pre-made commit message.
> +
> + It is also possible to use a different login name at the site
> + hosting the repo, by using:
> +
> + CHANGE_LOG_LOGIN=my_log_name
> +
> + With this, "make push" will use my_log_name, instead of the name for
> + the current unix user.
> +
> + Don't forget to export the vars at shell, with something like:
> +
> + export CHANGE_LOG_LOGIN HGUSER
> +
> + It is strongly recommended to have those lines in .bashrc or .profile.
> +
> +d) All patches shall have a Developers Certificate of Origin
> + version 1.1 in the commit log or the email description, signed by the
> + patch authors, as postulated in the Linux Kernel source at:
> +
> + Documentation/SubmittingPatches
> +
> + This is done by adding Signed-off-by: fields to the commit message.
> +
> + It is not acceptable to use fake signatures, e.g.:
> +
> + Signed-off-by: Fake me <me at snakeoilcompany.com>
> +
> + The email must be a valid one.
> + The author that is submitting the email should be at the botton of
> + the author's signed-off-by (SOB) block. Other SOBs or Acked-by: will be
> + added at the botton, marking that somebody else reviewed the patch.
> +
> + Each person who is in the kernel patch submission chain (driver author
> + and/or driver maintainer, subsystem/core maintainers, etc) will
> + review each patch. If they agree, the patch will be added to their
> + trees and signed. Otherwise, they may comment on the patch, asking
> + for some review.
> +
> +e) Although not documented at kernel's Documentation/, a common kernel
>
^remove at, use "in the"
> + practice is to use Acked-by: tag.
> +
> + An Acked-by: tag usually means that the acked person didn't write the
> + patch, nor is in the chain responsible for sending the patch to
> + kernel, but tested or reviewed the patch and agreed that it was good.
> +
> + A patch acked-by can be added at hg trees, if received by each tree
> + maintainer. It is also common to receive acks after having a patch
> + 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
> + 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:
> +
> + CC: someotherkerneldeveloper at someplace
> + Signed-off-by: nowere <nowere at noplace.org>
> +
> + This way, when a patch arrives mercurial hg tree, a mailbomb script
>
^ in the ?
> + will copy the proper interested parties.
> +
> + When submitting a patch via e-mail, it is better to copy all interested
>
^ remove better, best
> + parties direclty, by adding tmem as cc's to the email itself.
>
^them
> +
> + 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.
> +
> +g) Sometimes, mainstream changes affect the v4l-dvb tree, and mast be
>
^ remove
comma ^ remove comma
^fix must
> + 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:
> +
> + kernel-sync:
> +
> + Patches with this line will not be submitted upstream.
> +
> +h) 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.
> +
> + To allow compatibility tests, linux/version.h is automatically
> + included by the building system. This allows adding tests like:
> +
> + #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
> + #include <linux/kthread.h>
> + #endif
> +
> + It should be noticed, however, that an explicit inclusion of
> + linux/version.h is required if it is needed to use KERNEL_VERSION()
> + macro (this is required, for example, by V4L2 VIDIOC_QUERYCAP
> + ioctl), otherwise, the driver won't compile when submitted to kernel.
> +
> + There are several compatibility procedures already defined
> + in "compat.h" file. If needed, it is better to include it after all
> + other kernel standard headers, and before any specific header
> + for that file. Something like:
> +
> + #include <linux/kernel.h>
> + #include <linux/module.h>
> + ...
> + #include <linux/videodev2.h>
> + #include <media/v4l2-common.h>
> +
> + #include "compat.h"
> +
> + #include "mydriver-header.h"
> +
> +should be included at the
> + files under v4l-dvb tree. This header also includes linux/version.h.
>
^ did something get removed by mistake there? "should be .." text is
not aligned
> +
> + 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
> + be used, e.g:
> +
> + #if 0 /* keep */
> + or
> + #if 1 /* keep */
> +
> + The kernel submit scripts will remove the compatibility codes, the
> + tests for specific kernel versions and the #if 0/1 that doesn't have
> + the "keep meta tag".
> +
> + 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 developers's, a script is provided.
>
^developer's ... to a developer's tree?
> + This allows an easy import of mbox-based patch emails.
> + This is done with:
> +
> + ./mailimport <mbox file>
> +
> + For it to work properly, git tools need to be installed on the local
> + machine, since git has a gitimport script that is used by mailimport.
> + Also, hg has a feature, called mqueue, that allows having several patches
> + that can be applied/unapplied for testing. mailimport trusts on it to work,
> + so, this extension should be enabled for mailimport script to work.
> +
> +5. Knowing about newer patches commited at master hg repository
> + ============================================================
> +
>
>From this point onwards, the text alignment gets shifted to the left:
> +There's a patchbomb script at linuxtv.org that will send one copy of
> +each patch applied to -hg tree to:
> +
> +1) The subscribers of the video4linux-cvs at linuxtv.org mailing list (*);
> +
> +2) The patch author (as stated on the From: field in the patch comments);
> +
> +3) The patch committer (the "user" at hg metadata);
> +
> +4) All people with Signed-off-by:, Acked-by:, or CC: metadata clause
> + in the patch's comment.
> +
> +If, for some reason, there's no "From:" metatag (or it is on the first
> +line, instead of the second one), sometimes the script may fail, maybe
>
^ semi-colon
> +filling patch authorship wrongly. So people should take care to properly
>
^ maybe from filling patch authorship incorrectly.
> +commit patches with "From:".
> +
> +(*) Yes, we know that this is really a very bad name for this
> + list, since:
> + a) We don't use CVS anymore;
> + b) The script will post at this list any HG patches applied to
> + the main hg trees, including dvb-apps and v4l-dvb patches.
> +
> +6. Patch handling for kernel submission
> + ====================================
> +
> +The subsystem maintainer, when preparing the kernel patches to be sent
> +to mainstream (or to -mm series), uses some scripts and a manual
> +procedure, based on a quilt-like procedure, where a patch series file is
> +generated, and patches can be handled one by one. This means that -git
> +patches can be properly fixed, when required, if not already sent to
> +mainstream, to fulfill the best practices and resolve conflicts with
> +other patches directly merged in mainstream.
>
^ this last sentence could stand to see a rewrite. Maybe:
"This means that, when required, -git patches can be properly fixed if
they have not already been sent to mainstream, thereby resolving
conflicts with other patches directly merged into mainstream and
fulfilling the best practices." ?
> +
> +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;
> +
> +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;
> +
> +3) If somebody partially nacks a patch or sends a reviewing patch,
> +the -git patch may be a result of the merger of the two patches.
> +
> +By merging both patches at -git will allow avoiding storing unnecessary
>
^ remove "By" ^ remove
allow, ^ avoid
> +patch history details at -git and at Mainstream.
> +
> +Those changes will require some manual sync between -git and -hg, it is
> +better to avoid those circumstances.
> +
> +During the procedure of generating kernel patches, the maintainer uses
>
^ uses what?
> +to do a diff between the kernel tree and v4l-dvb mercurial tree
> +(without any backport code there). If there are discrepancies, a
> +backport patch from mainstream to v4l-dvb is generally applied by the
> +maintainer.
> +
> +7. Patch submission from the community
> + ===================================
> +
> +Patch submission is open to all the Free Software community. The general
> +procedure to have a patch accepted in the v4l/dvb subsystem and in the
> +kernel is the following:
> +
> +a. Post your patches to the corresponding mailing list for review and
> + test by other people.
>
^ testing
> +
> + For analog or core changes, the mailing list is
> + video4linux-list at redhat.com
> +
> + For DVB changes, the mailing list is
> + linux-dvb at linuxtv.org.
> +
> + PS.: Sending emails to DVB Mailing List requires subscription via
> + http://linuxtv.org/lists.php
> +
> +b. Use [PATCH] and a brief description in the email's subject.
> + This will help the LinuxTV team to better handle it.
>
^ assist the LinuxTV team with the handling
of your patch.
> +
> +c. Please include a brief description in the headers of your
> +patch, like described above. Something like:
> +
> + This is just a sample commit comment, just for reference purposes.
> + This does nothing.
> +
> + Signed-off-by nowere <nowere at noplace.org>
> +
> +d. Every patch shall have a Developers Certificate of Origin and should
> + be submitted by one of its authors. All the patch authors should sign
> + it.
> +
> +e. People will eventually comment about the patch. In this case,
> + please fix problems and repeat until everyone is happy ;)
> +
> +f. If the patch is fixing an existing maintained driver, the driver
> + maintainer will apply to his tree, and at some later time,
> + ask the subsystem maintainer to pull it.
> +
> +g. If it is a newer driver (not yet in one of the development trees),
> + please copy the subsystem maintainer.
> diff -r f71d56dfeb0d README.HG
> --- a/README.HG Wed Mar 07 12:28:33 2007 -0200
> +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
> @@ -1,206 +0,0 @@
> -Mauro Carvalho Chehab 2006 Mar 8
>
^ remove diff junk
> -
> -This file describes the general procedures used by v4l-dvb developers
> -who are responsible for maintaining V4L/DVB drivers. Some of these
>
^procedures
> -also applies to patch submitters.
>
^ apply
> -
> -Current V4L/DVB tree uses a modern SCM system that fits better into
> -kernel development model, called Mercurial (aka hg).
>
^ The Current V4L/DVB tree uses a modern SCM system, called Mercurial
(aka hg), that is well suited for end users and is complimentry the
kernel development model.
> -
> -There are some tutorials, FAQs and other valuable informations at
> -http://selenic.com/mercurial
> -
> -Mercurial is a distributed SCM, which means every developer gets his
>
^ remove his, use their
> -own full copy of the repository (including the complete revision
> -history), and can work and commit locally without network connection.
> -The resulting changesets can then be exchanged between repositories and
^change-sets ?
>
> -finally published to the master repository in linuxtv.org. A list of
> -current available repositories is available at: http://linuxtv.org/hg
> -
> -The master repository with stable patches is available at:
> -http://linuxtv/org/hg/v4l-dvb
> -
> -Mercurial is organized with a master tag, called tip. This tag contains
> -the master repository that will be used by normal users and to generate
> -patches to kernel.
> -
> -This file postulates some simple rules for maintaing hg trees, as stated
> -below:
> -
> -1) It is strongly recommended that each developer be active at IRC
> - channels (irc://irc.freenode.net) #v4l (for analog) and/or #linuxtv
> - (for digital). It helps to have more discussions at major changes;
>
^ during
> -
> -2) Each developer may have one or more development trees, for his daily
> - work. It is recommended to have a tree called 'v4l-dvb' for each
> - developer with their stable patches.
> -
> -3) After the patches are ready, developer should send an email to
>
^When patches are ready, the ....
> - v4l-dvb-maintainer list asking the maintainer to pull it from developer
> - repository, pushing it at master. The maintainer will analyse the patch
> - and publish at master hg if everything looks ok.
> -
> -4) Medium or major changes that needs modification on card coding, creating a
>
^ need
> - new card type or requiring changes at core structs should be discussed first
>
^remove at, use "in"
> - at the Mailing Lists video4linux-list at redhat.com (analog/common parts)
>
^ remove at, use "on"
> - and/or linux-dvb at linuxtv.org and at IRC to allow other contributors to
>
^
remove at, use "on"
> - discuss about the way it will be included.
>
^ remove about
> -
> -5) Every developer should follow the "rules of thumb" of kernel development
> - stated at Linux source code, especially:
> -
> - Documentation/SubmittingPatches
> - Documentation/SubmittingDrivers
> - Documentation/CodingStyle
> -
> -6) All commits should have a consistent message. On v4l-dvb, this is
> - done by using:
> -
> - make commit
> -
> - This will run some scripts that will check changed files, generating
> - a ChangeLog like comment (that will be removed from the commit) and
> - prepare the last Signed-off-by field, as described below.
> -
> -7) Files can be added, removed or renamed at hg repository. This should
> - be done by using:
> - hg add <files>
> - hg remove <files>
> - hg rename <source> <dest>
> - hg addremove [<files>]
> -
> - *Warning* hg addremove will add/removes all files, including object
> - files. Be careful! You can remove wrongly added files with hg remove.
> -
> -8) If the commit went wrong, hg allows you to undo the last commit, by
>
^ maybe "goes" instead of "went" ?
> - using the command:
> -
> - hg undo
> -
> - This command will preserve the changes at the files. So, a new
>
^ in ?
> - hg commit will redo the desired commit.
> -
> -9) To push the change to the repository you need to run:
> -
> - hg push <url>
> -
> -10) To update from the master repository, it is needed to do:
> -
> - make pull
> -
> - After pulling from master, if there are some changes at local repository,
>
^ in the
> - hg will require to merge it. This is done by
>
^ remove it, use
them
> - hg update -m
> - make commit
> -
> -11) For hg to work properly, these vars should be defined (replacing
>
^
variables
> - the names at the left):
> -
> - HGUSER="Maintainer Name <maintainer-email at cvsmaintainersite.com>"
> -
> - If you use a different login name at the repo, you may use:
> -
> - CHANGE_LOG_LOGIN=my_log_name
> -
> - You may also have it at ~/.hgrc, but, in this case, make commit will not
> - generate From: and Signed-off-by fields automatically.
> -
> - Don't forget to export the vars, like:
>
^ variables
> -
> - export CHANGE_LOG_LOGIN HGUSER
> -
> - It is strongly recommended to have these lines at .bashrc or .profile.
> -
> -12) All commit messages shall have a Developers Certificate of Origin
> - version 1.1 at commit log, as postulated at kernel's source at:
> -
> - Documentation/SubmittingPatches
> -
> - This is done by using Signed-off-by: fields at hg commit message.
> -
> - It is not acceptable to use fake signatures like:
> -
> - Signed-off-by: Fake me <me at snakeoilcompany.com>
> -
> - The email should be a valid one.
> - The bottom signed-off-by should be the committer.
> -
> -13) Commit messages are very relevant, since they will be used
> - when generating the patches for v4l-dvb.git and to mainstream.
> -
> - The format of commit message shall be:
> -
> - patch subject
> - From: Patch Developer <patchdeveloper at patchdevelopersite.com>
> -
> - patch descriptions
> -
> - Signed-off-by: Patch Developer <patchdeveloper at patchdevelopersite.com>
> - Signed-off-by: Cvs Maintainer <cvsmaintainer at cvsmaintainersite.com>
> -
> - All lines starting with # will be removed by make commit stripts.
> -
> - Subject should be a brief description of the patch. Please
> - notice that, with hg, there's no need (and not desired) to define a
> - Subject: tag. The *first* msg line will be used as subject, just like
> - git.
> - *WARNING* Be careful not to leave the first line blank, otherwise hg
> - will leave subject in blank.
> -
> - From: line shouldn't be suppressed, since it will be used when
>
^ should not
> - converting to -git as patch author.
> -
> - You may add other signers, if the patch were tested /co-developed
> - by somebody else and he also wants to sign. The committer
> - signed-off-by should be the last one.
> -
> -14) If the patch also affects other parts of kernel (like alsa
> - or i2c), it is required that, at upstream submitting, the patch
> - also goes to the maintainers of that subsystem. To do this, CVS
> - maintainer shall add one or more cc: fields to the commit message,
> - after the subject:
> -
> - CC: someotherkerneldeveloper at someplace
> -
> - Please notice that this is manually handled by the -git maintainer,
> - so unnecessary usage should be avoided.
> -
> -15) Sometimes, mainstream changes do affect v4l-dvb tree, and requires
>
^ the
> - to apply some kernel patches at the tree. This kind of commit should
>
^ that they are applied to the tree.
> - follow the rules above and should also have a line like:
> -
> - kernel-sync
> -
> - Patches with such lines will not be submitted upstream.
> -
> -16) 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.
> -
> - To allow compatibility tests, "compat.h" should be included first.
> - It does include also 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, this struct should be used:
> -
> - #if 0 /* keep */
> - or
> - #if 1 /* keep */
> -
> -17) Nested #ifs are allowed, but the #elif macro shouldn't be used,
>
^ should not
> - since the macro preprocessing script used to prepare kernel upstream
> - patches (v4l/scripts/gentree.pl) is not able to handle it.
>
^ since they are not handled by the macro preprocessing script
(v4l/scripts/gentree.pl) used to prepare kernel upstream patches.
Not really certain on that last bit of wording -- kernel upstream patches.
> -
> -18) To import contributed stuff, a script is provided at tree and allows easy
>
^ "in the" instead of "at" ?
> - import of a mbox-based patch emails. This is done with:
> - ./mailimport <mbox file>
> - For it to work properly, git tools need to be installed at local machine,
>
^ remove at, use "on the"
> - since git have a gitimport script that is used by mailimport.
>
^ has
> - Also, hg have a feature, called mqueue, that allows having several patches
>
^ has ^ remove comma ^ remove
comma
> - that can be applied/unapplied for testing. mailimport trusts on it to work,
> - so, this extension should be enabled for mailimport script to work.
> -
> -Good Work!
> -Mauro
> -
> -Mauro Carvalho Chehab <mchehab .at. linuxtv .dot. org>
>
More information about the linux-dvb
mailing list