Maintaining Mercurial (Hg) trees

From LinuxTVWiki

(Difference between revisions)
Jump to: navigation, search
(Updates)
Line 1: Line 1:
-
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/video4linux/ v4l downloads page].
+
== Where is the source code? ==
-
These are some simple rules that gives some directions for maintaing CVS tree:
+
Up until 2006-01-30, the source code for the v4l kernel modules was available via CVS; cf. [[How to build from CVS]]. There are old snapshots available from  [http://www.linuxtv.org/downloads/video4linux/ June to November 2005]. Before that, the code was housed at [http://dl.bytesex.org/patches/ Gerd Knorr's site].
-
1) Every CVS maintainer should be active at [irc://irc.freenode.net/v4l #V4L IRC channel]. It helps
+
As of 2006-01-30, V4L and DVB kernel modules are available via [http://www.selenic.com/mercurial/wiki/index.cgi Mercurial], a lightweight Source Control Management system. See the current [http://linuxtv.org/repo/ instructions for source access].  
-
to have more discussions at major changes;
+
-
2) Minor changes, like simple card additions (only a card row at card
+
The guidelines below are dated, as the source is now maintained in Mercurial rather than CVS.
-
struct) can be applied directly for the CVS maintainer;
+
-
3) Medium changes that needs modification on card coding or creating a
+
== Guidelines for contributors ==
-
new card type should be discussed at [irc://irc.freenode.net/v4l #V4L IRC channel] to allow other
+
-
contributors to discuss about the way it will be included. V4L
+
-
maintainer should be warned to create a snapshot (if the change could
+
-
generate impacts on other cards) BEFORE commiting the change to CVS;
+
-
4) Major changes that implies changing some core structs should be
+
These are some simple rules that gives some directions for maintaing CVS tree:
-
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
+
# Every CVS maintainer should be active at [irc://irc.freenode.net/v4l #V4L IRC channel]. It helps to have more discussions at major changes<br>
-
development like:
+
# Minor changes, like simple card additions (only a card row at card struct) can be applied directly for the CVS maintainer<br>
-
* [[SubmittingPatches | Kernel rules to submit patches]]
+
# Medium changes that needs modification on card coding or creating a new card type should be discussed at [irc://irc.freenode.net/v4l #V4L IRC channel] to allow other contributors to discuss about the way it will be included. V4L maintainer should be warned to create a snapshot (if the change could  generate impacts on other cards) BEFORE commiting the change to CVS<br>
-
* [[Documentation/SubmittingDrivers | Kernel rules to submit drivers]]
+
# Major changes that implies changing some core structs should be discussed on IRC, posted to the list, created a snapshot THEN committed to CVS<br>
-
* [[Documentation/CodingStyle | Kernel Coding Style]]
+
# Every CVS maintainer should follow the "rules of thumb" of kernel development like:
 +
#* [[SubmittingPatches | Kernel rules to submit patches]]
 +
#* [[Documentation/SubmittingDrivers | Kernel rules to submit drivers]]
 +
#* [[Documentation/CodingStyle | Kernel Coding Style]]<br>
 +
#People interested in being a CVS maintainer should participate at IRC, before requesting changing access to V4L CVS<br>
 +
# Non active CVS maintainers or that doesn't like to follow the above rules may be dropped<br>
 +
# Every commit should update ChangeLog describing who did, what changed and in what files. It should also have [[ SubmittingPatches#Developer.27s_Certificate_of_Origin_1.1|Developer's Certificate of Origin 1.1 ]] for each patch contributor. The best way for generating it is using '''make changes''' The bottom signed-off-by should be the CVS maintainer, as in this example:
-
6) People interested in being a CVS maintainer should participate at IRC,
 
-
before requesting changing access to V4L CVS.
 
-
 
-
7) Non active CVS maintainers or that doesn't like to follow the above
 
-
rules may be dropped.
 
-
 
-
        8) Every commit should update ChangeLog describing who did, what changed and in what files.
 
-
It should also have [[ SubmittingPatches#Developer.27s_Certificate_of_Origin_1.1|Developer's Certificate of Origin 1.1 ]] for each patch contributor.
 
-
The best way for generating it is using '''make changes'''
 
-
The bottom signed-off-by should be the CVS maintainer.
 
-
 
-
This is an example:
 
-
 
   2005-06-28 18:35  cvsmaintainer
   2005-06-28 18:35  cvsmaintainer
         * filelist.c, filelist.h:
         * filelist.c, filelist.h:
-
         - described changes.
+
         - described changes.<br>
-
+
         Signed-off-by: Patch Developer <patchdeveloper@patchdevelopersite.com>
         Signed-off-by: Patch Developer <patchdeveloper@patchdevelopersite.com>
-
         Signed-off-by: Cvs Maintainer <cvsmaintainer@cvsmaintainersite.com>
+
         Signed-off-by: Cvs Maintainer <cvsmaintainer@cvsmaintainersite.com><br>
-
+
 
-
Obs.: Timestamp should be in GMT
+
Note: The timestamp should be in GMT.<br>
-
        9) Commit messages are very rellevant, since they will be used when generating the patches for mainstream.
+
:9Commit messages are critically important, as they will be used to generate the patches for mainstream. The format is as follows:<br>
-
      The format shall be:
+
  '''Subject:''' ''patch subject - only one line describing the entire patch''
  '''Subject:''' ''patch subject - only one line describing the entire patch''
-
  '''From:''' ''optional - only one line with the author of the patch''
+
  '''From:''' ''optional - only one line with the author of the patch'' ''patch descriptions''
-
''patch descriptions''
+
  '''Signed-off-by:''' ''one line by signer - should include the patch commiter and the author''
  '''Signed-off-by:''' ''one line by signer - should include the patch commiter and the author''

Revision as of 08:11, 20 March 2006

Where is the source code?

Up until 2006-01-30, the source code for the v4l kernel modules was available via CVS; cf. How to build from CVS. There are old snapshots available from June to November 2005. Before that, the code was housed at Gerd Knorr's site.

As of 2006-01-30, V4L and DVB kernel modules are available via Mercurial, a lightweight Source Control Management system. See the current instructions for source access.

The guidelines below are dated, as the source is now maintained in Mercurial rather than CVS.

Guidelines for contributors

These are some simple rules that gives some directions for maintaing CVS tree:

  1. Every CVS maintainer should be active at #V4L IRC channel. It helps to have more discussions at major changes
  2. Minor changes, like simple card additions (only a card row at 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 at #V4L IRC channel to allow other contributors to discuss about the way it will be included. V4L maintainer should be warned to create a snapshot (if the change could generate impacts on other cards) BEFORE commiting the change to CVS
  4. Major changes that implies changing some core structs should be 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 like:
  6. People interested in being a CVS maintainer should participate at IRC, before requesting changing access to V4L CVS
  7. Non active CVS maintainers or that doesn't like to follow the above rules may be dropped
  8. Every commit should update ChangeLog describing who did, what changed and in what files. It should also have Developer's Certificate of Origin 1.1 for each patch contributor. The best way for generating it is using make changes The bottom signed-off-by should be the CVS maintainer, as in this example:
 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>

Note: The timestamp should be in GMT.

9. Commit messages are critically important, as they will be used to generate the patches for mainstream. The format is as follows:
Subject: patch subject - only one line describing the entire patch
From: optional - only one line with the author of the patch patch descriptions
Signed-off-by: one line by signer - should include the patch commiter and the author

---

Some quotations about development:

"The most difficult problem isn't fixing bugs, but fixing bugs without breaking other configurations. There are many: different cards, different TV norms, whereas most of the developers can test only one TV norm." - Gerd Knorr


"Anyone who has never made a mistake has never tried anything new." - Albert Einstein

Personal tools