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>
|