summaryrefslogtreecommitdiff
path: root/README.CVS
blob: b0c531b2ed659608e26bd1ba49a04d150730a66a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
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>