diff options
Diffstat (limited to 'README.HG')
| -rw-r--r-- | README.HG | 42 |
1 files changed, 23 insertions, 19 deletions
@@ -1,6 +1,6 @@ Mauro Carvalho Chehab 2006 Jan 28 - This file describes general procedures used by v4l-dvb + This file describes the general procedures used by v4l-dvb maintainers. Some of these also applies to patch submitters. We've moved from cvs to a modern SCM system that fits better @@ -26,7 +26,7 @@ should be done to avoid this. There are more "stable" snapshots at http://www.linuxtv.org/downloads/snapshot page. This file postulates some simple rules for maintaing hg tree, -as stated bellow: +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 @@ -50,21 +50,21 @@ to use a branch or v4l_experimental area for such changes. 5) Every CVS maintainer should follow the "rules of thumb" of kernel development stated at Linux source code, especially: - Documenation/SubmittingPatches + Documentation/SubmittingPatches Documentation/SubmittingDrivers Documentation/CodingStyle - 6) Every commit should update ChangeLog describing who did, -what changed and in what files, by using the command: + 6) Every commit should update the ChangeLog describing who made the +change, what changed and in what files, by using the command: make changes 7) The latest changelog line will be automatically used as a -prototype to the commit message at the local repository by using: +prototype to the commit message at the *LOCAL* repository by using: make commit - 8) if commit go wrong, hg allows you to undo the last commit, + 8) If the commit went wrong, hg allows you to undo the last commit, by using the command: hg undo @@ -72,7 +72,11 @@ by using the command: This command will preserve the changes at the files. So, a new hg commit will redo the desired commit. - 9) To update master repository, it is needed to do: + 9) To push the change to the *MASTER* repository you need to run: + + make push + + 9) To update from the master repository, it is needed to do: make pull @@ -96,7 +100,7 @@ kernel's source at: This is done by using Signed-off-by: fields at hg commit message. - It is not acceptable fake signatures like: + It is not acceptable to use fake signatures like: Signed-off-by: Fake me <me@snakeoilcompany.com> The email should be a valid one. @@ -113,7 +117,7 @@ kernel's source at: Obs.: Timestamp should be in GMT. - 12) Commit messages are very rellevant, since they will be used + 12) 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: @@ -127,20 +131,20 @@ 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. Please -notice that, with hg, There's no need (and not desired) to define a +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. From: shouldn't be suppressed You may add other signers, if the patch were tested by somebody -else and he also wants to sign. The commiter signed-off-by should be +else and he also wants to sign. The committer signed-off-by should be the last one. 13) If the patch also affects other parts of kernel (like alsa -or i2c), it is required that, at upstream submiting, the patch also go +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 at commit message, after the subject: +add one or more cc: fields to the commit message, after the subject: CC: someotherkerneldeveloper@someplace @@ -153,23 +157,23 @@ should follow the rules above and should also have a line like: kernel-sync - Patches with such lines will not be submited upstream. + Patches with such lines will not be submitted upstream. - 15) sometimes, it is necessary to introduce some testing code + 15) sometimes it is necessary to introduce some testing code inside a module or remove parts that are not yet finished. Also, -compatibility tests maybe required to provide backporting. +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 shuld be used: +If this code is meant to go also to kernel, this struct should be used: #if 0 /* keep */ or #if 1 /* keep */ - 16) Nested #ifs are allowed, but #elsif macro shouldn't be + 16) Nested #ifs are allowed, but the #elif 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. |