summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGerd Knorr <devnull@localhost>2005-04-26 09:01:28 +0000
committerGerd Knorr <devnull@localhost>2005-04-26 09:01:28 +0000
commitc47bf948dd3c46e96f2260f76b6e1b3d176cc868 (patch)
tree382334e9373a0cbe0db57a847a054c62f51340c1
parent21e32bf089c2a7b65e52d612a613187779bbe9bd (diff)
downloadmediapointer-dvb-s2-c47bf948dd3c46e96f2260f76b6e1b3d176cc868.tar.gz
mediapointer-dvb-s2-c47bf948dd3c46e96f2260f76b6e1b3d176cc868.tar.bz2
- update README.patches
-rw-r--r--v4l/README.patches57
1 files changed, 35 insertions, 22 deletions
diff --git a/v4l/README.patches b/v4l/README.patches
index 8f58802cd..f429749b1 100644
--- a/v4l/README.patches
+++ b/v4l/README.patches
@@ -1,32 +1,45 @@
April 2005
-
Hi folks,
As you may have noticed on lkml and the v4l mailing list, I've stopped
-maintaining video4linux in the linux kernels. That means for submitting
-patches:
-
- (1) The cvs tree at cvs.bytesex.org is *not* the "master copy" of the
- video4linux subsystem any more. For the time being it is the 2.6
- standard kernel. This may change if someone else decides to take
- over maintainance and handle it differently ...
-
- (2) Patches should be built against the latest 2.6 kernel[1], not
- against video4linux cvs, and submitted the usual way to akpm+lkml
- (Cc'ing the v4l list as well probably is a good idea). The usual
- rules (reasonable changelog entry and so on, see
- Documentation/SubmittingPatches) apply.
-
- (3) It is fine to Cc: me on patches for comments / ack / nack, but
- don't expect me to collect and forward patches. I've accumulated
- a number of v4l patches in my inbox last month, didn't managed to
- process a single one of them so far due to limited time, and I
- suspect this isn't going to change in the future ...
+maintaining video4linux in the linux kernels. That means:
+
+ * The cvs tree at cvs.bytesex.org is *not* the "master copy" of the
+ video4linux subsystem any more. For the time being it is the 2.6
+ standard kernel. This may change if someone else decides to take
+ over maintainance and handle it differently ...
+
+ * Patches should be built against the latest 2.6 kernel, not
+ against video4linux cvs.
+
+ * I've accumulated a number of v4l patches in my inbox last month,
+ didn't managed to process a single one of them so far due to
+ limited time, and I suspect this isn't going to change in the
+ future ...
+
+How to get your changes into the mainline tree?
+
+ (1) Post your patches to the video4linux mailing list[1] for
+ review and testing by other people. Fix problems and
+ repeat until everyone is happy ;)
+
+ (2) Create a nice patch with changelog and everything, have
+ a look at the Documentation/SubmittingPatches guidelines
+ for the details. Make sure the patch applies fine against
+ the latest kernel (prefearable the latest -mm kernel).
+
+ (3) Submit the patch. Mail it to the kernel mailing list[2]
+ and Andrew Morton[3] (the guy maintaining the -mm tree).
+ It's fine to Cc: me here, that probably makes it easier
+ to get the changes accepted because I can comment in case
+ there are questions or objections from Andrew or other
+ guys on the kernel list.
cheers,
Gerd
-[1] Very latest kernel is especially important for patches which add
- new card entries as those patches usually conflict ...
+[1] https://www.redhat.com/mailman/listinfo/video4linux-list
+[2] linux-kernel@vger.kernel.org
+[3] Andrew Morton <akpm@osdl.org>