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 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 Signed-off-by: Cvs Maintainer 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 patch descriptions Signed-off-by: Patch Developer Signed-off-by: Cvs Maintainer 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