lkml.org 
[lkml]   [2005]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: MM kernels - how to keep on the bleeding edge?
Michael Krufky wrote:

> However, sometimes there are patches in -mm that are incompatable with
> -linus. An example of this is "Pavel's pm_message_t mangling" ...
> Testing for the numbered 2.6.x version isn't enough of a test in a
> case like this, but it would be nice to be able to develop against the
> most recent version of both the -mm tree and the -linus tree without
> having to revert patches. Of course, v4l has chosen to maintain
> compatibility with -mm, for the sake of patch generation, and I have a
> handy -linus-compat.patch on the side for now if I want to build cvs
> against -linus, until Pavel's patches get merged later on. But I'm
> sure things like this must happen all the time. How do others deal
> with issues like these automatically?
>
> It doesn't matter which -mm version or which -linus version it is... I
> can already test for 2.6.x ... All that matters is if it is -mm or
> -linus. If there isn't already an answer to this question, maybe you
> can create a /linux/.mm file, or something like that. A Makefile can
> test for the presence of that file... or is there already a file
> present that is unique to the -mm tree?
>
Here's a patch, if you so choose to go this route.....

This should NEVER be merged to -linus ;-)

Signed-off-by: Michael Krufky <mkrufky@m1k.net>



diff -upN a/.mm b/.mm
--- a/.mm 1970-01-01 00:00:00.000000000 +0000
+++ b/.mm 2005-07-26 20:57:41.000000000 +0000
@@ -0,0 +1 @@
+1
\
 
 \ /
  Last update: 2005-07-27 03:05    [W:0.079 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site