diff options
Diffstat (limited to 'README.CVS')
| -rw-r--r-- | README.CVS | 123 |
1 files changed, 0 insertions, 123 deletions
diff --git a/README.CVS b/README.CVS deleted file mode 100644 index b0c531b2e..000000000 --- a/README.CVS +++ /dev/null @@ -1,123 +0,0 @@ -Mauro Carvalho Chehab 2005 Dec 08 - - CVS is a developer database, It means that it might be broken -from time to time. There are more "stable" snapshots at -http://www.linuxtv.org/downloads/snapshot page. - - This file postulates some simple rules for maintaing CVS tree, -as stated bellow: - - 1) It is strongly recommended that CVS maintainers be active at -IRC (irc://irc.freenode.net) #v4l (analog) and/or #linuxtv (digital) -channels. It helps to have more discussions at major changes; - - 2) Minor changes, like simple card additions (only a card row at -a card struct) can be applied directly for the CVS maintainer; - - 3) Medium changes that needs modification on card coding or -creating a new card type should be discussed first at the Mailing Lists -video4linux-list .at. redhat .dot. com (analog/common parts) and/or -linux-dvb .at. linuxtv .dot. org to allow other contributors to discuss -about the way it will be included. The v4l-dvb maintainer should be -warned to create a snapshot (if the change could generate impacts on -other cards) BEFORE commiting the change to CVS at -v4l-dvb-maintainer .at. linuxtv .dot. org; - - 4) Major changes that implies changing some core structs should -be widely discussed on IRC, posted to the list, created a snapshot THEN -committed to CVS. - - 5) Every CVS maintainer should follow the "rules of thumb" of kernel - development stated at Linux source code, especially: - Documenation/SubmittingPatches - Documentation/SubmittingDrivers - Documentation/CodingStyle - - 6) Non active CVS maintainers or that doesn't like to follow these - rules may be dropped. - - 8) Every commit should update ChangeLog describing who did, what -changed and in what files, by using the command: - make changes - - For it to work, these vars should be defined (replacing the -names at the left): - -CHANGE_LOG_NAME="CVS maintainer" -CHANGE_LOG_EMAIL_ADDRESS=cvsmaintainer@cvsmaintainersite.com -CHANGE_LOG_LOGIN=cvsuser -export CHANGE_LOG_NAME CHANGE_LOG_EMAIL_ADDRESS CHANGE_LOG_LOGIN - - It is recommended to have these lines at .bashrc or .profile. - - 9) It shall also have a Developers Certificate of Origin version -1.1 at Changelog and cvs commit log, as postulated at kernel's source at: - Documentation/SubmittingPatches - - This is done by using Signed-off-by: fields at cvs commit message. - - It is not acceptable fake signatures like: - Signed-off-by: Fake me <me@snakeoilcompany.com> - - The email should be a valid one. - The bottom signed-off-by should be the CVS maintainer. - - This is an example of ChangeLog entry: - - 2005-06-28 18:35 cvsmaintainer - * filelist.c, filelist.h: - - described changes. - - Signed-off-by: Patch Developer <patchdeveloper@patchdevelopersite.com> - Signed-off-by: Cvs Maintainer <cvsmaintainer@cvsmaintainersite.com> - - Obs.: Timestamp should be in GMT. - - 10) Commit messages are very rellevant, since they will be used -when generating the patches for mainstream. - The format of commit message shall be: -Subject: patch subject -From: Patch Developer <patchdeveloper@patchdevelopersite.com> - -patch descriptions - -Signed-off-by: Patch Developer <patchdeveloper@patchdevelopersite.com> -Signed-off-by: Cvs Maintainer <cvsmaintainer@cvsmaintainersite.com> - - Subject: should be a brief description of the patch; - From: should be suppressed if the patch is from the CVS maintainer - You may add other signers, if the patch were tested by somebody -else and he also wants to sign. - - 11) if the patch also affects other parts of kernel (like alsa -or i2c), it is required that, at upstream submiting, the patch also go -to the maintainers of that piece. To do this, CVS maintainer shall add -one or more cc: fields at commit cvs message: - -CC: someotherkerneldeveloper@someplace - - 12) Sometimes, mainstream changes do affect CVS tree, and -requires to apply some kernel patches at the tree. This kind of commit -should follow the rules above and should also have a line like: - -kernel-sync - - Patches with such lines will not be submited upstream. - - 13) sometimes, it is necessary to introduce some testing code -or remove parts that are not yet finished. Also, compatibility tests -maybe required. - 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 shuld be used: -#if 0 /* keep */ - or -#if 1 /* keep */ - - 14) Nested #ifs are allowed, but #elsif macro shouldn't be used, -since the macro preprocessing script used to prepare kernel upstream -patches (v4l/scripts/gentree.pl) is not able to handle it. - -Mauro -Mauro Carvalho Chehab <mchehab .at. linuxtv .dot. org> |