MM kernels - how to keep on the bleeding edge?

MM kernels - how to keep on the bleeding edge?

[Radoslaw AstralStorm Szkodzinski]

[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

I've a question on how to keep in touch with all those patches going into mm
patchset. Yes, I know of and am subscribed to mm-commits list, but it has a
few shortcomings: 
a) It doesn't tell which patches went into the mainline.
That's not necessary, as there's always git, but comparing on commit messages
seems awkward and the contents aren't necessarily the same.

Maybe AM has some algorithm to determine which patches went in and which,
say, went in only in part? 
Or that he redoes all the patches against the newest Linus' tree?
Anyway, I'd like to know what was the tree version at the time.

b) It doesn't say which -mm version are they in.
This is a real PITA, because I have to check patch list one after one to
apply to the newest mm. A message consisting of: 

Subject: 2.6.x-mmy released

Contains all patches up to:
 abc-fix.patch

Is based on Linus' tree up to commit:
  xyzabc123

would be more than enough.
This way it would be easy to update the latest patchset to the latest and
(hopefully) greatest mailing list patch. As it is now, I have to do a search
every time I blow up the tree.

It would be much easier for me if there was a mercurial or git tree with mm
patches available somewhere, but I can live with my mail reading script.

(I'm not subscribed to the list at the time - my mailbox would blow up)

-- 
AstralStorm

GPG Key ID = 0xD1F10BA2
GPG Key fingerprint = 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2
Please encrypt if you can.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MM kernels - how to keep on the bleeding edge?

[Michael Krufky]

Radoslaw AstralStorm Szkodzinski wrote:

> b) It doesn't say which -mm version are they in.
> This is a real PITA, because I have to check patch list one after one to
> apply to the newest mm.

I have filters set up so that my mailer puts all mm-commits messages 
from the mailing list into a special "mm-commits" folder.  Each time 
Andrew releases an -mm kernel, I rename my "mm-commits" folder to 
"mm-commits-%version%", such as "mm-commits-2.6.13-rc3-mm2"  (I will 
probably have to create a folder like this tomorrow, or in a few 
hours/days ;-) ... Then I create a new "mm-commits" folder to hold all 
new patches not yet in the latest -mm kernel.  As of right now, my 
current "mm-commits" mail folder has 153 patches in it, although I think 
I may have lost a patch or two...

ALSO, somebody has created a -git tree that pulls from the mm-commits 
list (i think) ... Anyway, I looked at the git tree last night and it 
seems to be delayed by a few days.  I dont have that link handy right 
now.  Does anybody else have it?

-- 
Michael Krufky

Re: MM kernels - how to keep on the bleeding edge?

[Radoslaw AstralStorm Szkodzinski]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

On Tue, 26 Jul 2005 15:45:41 -0400
Michael Krufky <mkrufky@m1k.net> wrote:

> I have filters set up so that my mailer puts all mm-commits messages 
> from the mailing list into a special "mm-commits" folder.  Each time 
> Andrew releases an -mm kernel, I rename my "mm-commits" folder to 
> "mm-commits-%version%", such as "mm-commits-2.6.13-rc3-mm2"  (I will 
> probably have to create a folder like this tomorrow, or in a few 
> hours/days ;-) ... Then I create a new "mm-commits" folder to hold all 
> new patches not yet in the latest -mm kernel.  As of right now, my 
> current "mm-commits" mail folder has 153 patches in it, although I think 
> I may have lost a patch or two...

The problem is detecting if or when the latest -mm got created.
If I have to do it by hand, it becomes a major PITA.
I could use RSS to do this, but some patches may still hit the wrong
folder. What's more it would create unnecessary network load.
There are sometimes only a few minutes between "patch in -mm1"
and "patch in -mm2".

-- 
AstralStorm

GPG Key ID = 0xD1F10BA2
GPG Key fingerprint = 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2
Please encrypt if you can.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MM kernels - how to keep on the bleeding edge?

[Michael Krufky]

Radoslaw AstralStorm Szkodzinski wrote:

>On Tue, 26 Jul 2005 15:45:41 -0400
>Michael Krufky <mkrufky@m1k.net> wrote:
>
>> have filters set up so that my mailer puts all mm-commits messages 
>>from the mailing list into a special "mm-commits" folder.  Each time 
>>Andrew releases an -mm kernel, I rename my "mm-commits" folder to 
>>"mm-commits-%version%", such as "mm-commits-2.6.13-rc3-mm2"  (I will 
>>probably have to create a folder like this tomorrow, or in a few 
>>hours/days ;-) ... Then I create a new "mm-commits" folder to hold all 
>>new patches not yet in the latest -mm kernel.  As of right now, my 
>>current "mm-commits" mail folder has 153 patches in it, although I think 
>>I may have lost a patch or two...
>>    
>>
>The problem is detecting if or when the latest -mm got created.
>If I have to do it by hand, it becomes a major PITA.
>I could use RSS to do this, but some patches may still hit the wrong
>folder. What's more it would create unnecessary network load.
>There are sometimes only a few minutes between "patch in -mm1"
>and "patch in -mm2".
>
There's an RSS feed for -mm ??? Where is that located?

-- 
Michael Krufky

Re: MM kernels - how to keep on the bleeding edge?

[Andrew Morton]

Michael Krufky <mkrufky@m1k.net> wrote:
>
> [ tracking mm stuff ]
>

Sigh, sorry.  It's hard.  -mm is always in flux.  I no longer send out the
`patch was dropped' message because it disturbs people.  The mm-commits
list does not resend a patch when it is changed (other patches folded into
it, rejects fixed, changelog updated, rediffed, etc).  Sometimes I'll
comment out a patch but not fully drop it.  I pull all the git trees at
least twice a day and that's not reflected on the mm-commits list either.

You can always tell when a -mm release is coming by watching the shower of
stupid compile fixes emerging :(

I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5
times a day), but there's no guarantee that it'll compile, let alone run. 
I could also send a notification to mm-commits when I do so.  Would that
help?

Re: MM kernels - how to keep on the bleeding edge?

[Andrew Morton]

Andrew Morton <akpm@osdl.org> wrote:
>
> I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5
> times a day), but there's no guarantee that it'll compile, let alone run. 
> I could also send a notification to mm-commits when I do so.  Would that
> help?

OK, I did that.

The directory at kernel.org will get quite large, so I'll probably manually
delete things occasionally.

The kernel.org propagation delay is a bit of a hassle.  I could use
zip.com.au but I suspect they hate me enough already.

Re: MM kernels - how to keep on the bleeding edge?

[Radoslaw AstralStorm Szkodzinski]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

On Tue, 26 Jul 2005 14:41:49 -0700
Andrew Morton <akpm@osdl.org> wrote:

> Michael Krufky <mkrufky@m1k.net> wrote:
> >
> > [ tracking mm stuff ]
> >
> 
> Sigh, sorry.  It's hard.  -mm is always in flux.  I no longer send out the
> `patch was dropped' message because it disturbs people. 

There were too many? 
Or you were receiving a lot of mail from particular developers with
requests of explanation? :)

> The mm-commits
> list does not resend a patch when it is changed (other patches folded into
> it, rejects fixed, changelog updated, rediffed, etc).  

This isn't so much a problem as the previous point. When there are rejects,
it's easy (most of the time) to fix them by hand anyway as I pull the tree.

> Sometimes I'll comment out a patch but not fully drop it.  

Now I can see that, I can diff the series. 
But if the change was large, the diff isn't very instructive.

> I pull all the git trees at
> least twice a day and that's not reflected on the mm-commits list either.
> 

That's not a problem, I can pull them too. They're public.

> You can always tell when a -mm release is coming by watching the shower of
> stupid compile fixes emerging :(

I do notice that using the RSS already, :) And the usual shower isn't as
frequent and large nowadays as before.

> 
> I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5
> times a day), but there's no guarantee that it'll compile, let alone run. 
> I could also send a notification to mm-commits when I do so.  Would that
> help?
> 

Really, it would. Especially if it contained an up-to-date series file.
I'd be very grateful. (And would test and fix it up some more.)

-- 
AstralStorm

GPG Key ID = 0xD1F10BA2
GPG Key fingerprint = 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2
Please encrypt if you can.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MM kernels - how to keep on the bleeding edge?

[Radoslaw AstralStorm Szkodzinski]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Tue, 26 Jul 2005 15:32:51 -0700
Andrew Morton <akpm@osdl.org> wrote:

> Andrew Morton <akpm@osdl.org> wrote:
> >
> > I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5
> > times a day), 
> <snip>
> OK, I did that.
> 

Great!

> The kernel.org propagation delay is a bit of a hassle.  I could use
> zip.com.au but I suspect they hate me enough already.
> 

Right now the delay is about one hour. I can certainly live with that.

-- 
AstralStorm

GPG Key ID = 0xD1F10BA2
GPG Key fingerprint = 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2
Please encrypt if you can.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MM kernels - how to keep on the bleeding edge?

[Andrew Morton]

Radoslaw "AstralStorm" Szkodzinski <astralstorm@gorzow.mm.pl> wrote:
>
> On Tue, 26 Jul 2005 14:41:49 -0700
> Andrew Morton <akpm@osdl.org> wrote:
> 
> > Michael Krufky <mkrufky@m1k.net> wrote:
> > >
> > > [ tracking mm stuff ]
> > >
> > 
> > Sigh, sorry.  It's hard.  -mm is always in flux.  I no longer send out the
> > `patch was dropped' message because it disturbs people. 
> 
> There were too many? 
> Or you were receiving a lot of mail from particular developers with
> requests of explanation? :)

I got lots of "waah, why did you drop my patch" from people whose patches
had been merged by Linus.  Which is a bit odd given that those people were
previously cc'ed on the me->linus patch anyway.  Ho hum.  Adding a "why
this was dropped" to the email seemed too tricky.

> > The mm-commits
> > list does not resend a patch when it is changed (other patches folded into
> > it, rejects fixed, changelog updated, rediffed, etc).  
> 
> This isn't so much a problem as the previous point. When there are rejects,
> it's easy (most of the time) to fix them by hand anyway as I pull the tree.
> 
> > Sometimes I'll comment out a patch but not fully drop it.  
> 
> Now I can see that, I can diff the series. 
> But if the change was large, the diff isn't very instructive.

OK.  I'm uploading the stripped series file at present (all the comments
are removed) because some versions of quilt don't like my new
comments-at-the-end-of-the-line feature.  That actually breaks some of my
stuff too, so I'll probably stop using it ;)

> > 
> > I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5
> > times a day), but there's no guarantee that it'll compile, let alone run. 
> > I could also send a notification to mm-commits when I do so.  Would that
> > help?
> > 
> 
> Really, it would. Especially if it contained an up-to-date series file.
> I'd be very grateful. (And would test and fix it up some more.)

All done - let me know if it needs anything else.

Re: MM kernels - how to keep on the bleeding edge?

[Radoslaw AstralStorm Szkodzinski]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Tue, 26 Jul 2005 16:11:49 -0700
Andrew Morton <akpm@osdl.org> wrote:

> 
> All done - let me know if it needs anything else.
> 

You got me with a tarball w/o a directory inside. Now I have to clean up the mess.
Not the first time in life. I think I'll never learn. :)

-- 
AstralStorm

GPG Key ID = 0xD1F10BA2
GPG Key fingerprint = 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2
Please encrypt if you can.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MM kernels - how to keep on the bleeding edge?

[Andrew Morton]

Radoslaw "AstralStorm" Szkodzinski <astralstorm@gorzow.mm.pl> wrote:
>
> On Tue, 26 Jul 2005 16:11:49 -0700
> Andrew Morton <akpm@osdl.org> wrote:
> 
> > 
> > All done - let me know if it needs anything else.
> > 
> 
> You got me with a tarball w/o a directory inside. Now I have to clean up the mess.
> Not the first time in life. I think I'll never learn. :)

I did?

bix:/home/akpm/.mm> tar tvfj broken-out-2005-07-26-15-07.tar.bz2 | head
-rw-r--r-- akpm/akpm     35426 2005-07-26 15:10:32 series
-rw-r--r-- akpm/akpm    593326 2005-07-26 12:46:37 patches/linus.patch
-rw-r--r-- akpm/akpm      3076 2005-07-16 14:28:43 patches/i2c-mpc-restore-code-removed.patch
-rw-r--r-- akpm/akpm       888 2005-07-16 14:28:45 patches/really-__nocast-annotate-kmalloc_node.patch
-rw-r--r-- akpm/akpm      3071 2005-07-26 00:37:34 patches/mips-fbdev-kconfig-fix.patch
-rw-r--r-- akpm/akpm      4097 2005-07-26 00:37:34 patches/max_user_rt_prio-and-max_rt_prio-are-wrong.patch
-rw-r--r-- akpm/akpm      2053 2005-07-26 00:39:53 patches/md-when-resizing-an-array-we-need-to-update-resync_max_sectors-as-well-as-size.patch
-rw-r--r-- akpm/akpm       946 2005-07-26 00:39:55 patches/uml-readd-missing-define-to-arch-um-makefile-i386.patch

Re: MM kernels - how to keep on the bleeding edge?

[Randy Dunlap]

Andrew Morton said:
> Radoslaw "AstralStorm" Szkodzinski <astralstorm@gorzow.mm.pl> wrote:
>>
>> On Tue, 26 Jul 2005 16:11:49 -0700
>> Andrew Morton <akpm@osdl.org> wrote:
>>
>> >
>> > All done - let me know if it needs anything else.
>> >
>>
>> You got me with a tarball w/o a directory inside. Now I have to clean
>> up the mess.
>> Not the first time in life. I think I'll never learn. :)
>
> I did?

I thought that he meant without a top-level directory...


> bix:/home/akpm/.mm> tar tvfj broken-out-2005-07-26-15-07.tar.bz2 | head
> -rw-r--r-- akpm/akpm     35426 2005-07-26 15:10:32 series
> -rw-r--r-- akpm/akpm    593326 2005-07-26 12:46:37 patches/linus.patch
> -rw-r--r-- akpm/akpm      3076 2005-07-16 14:28:43
> patches/i2c-mpc-restore-code-removed.patch
> -rw-r--r-- akpm/akpm       888 2005-07-16 14:28:45
> patches/really-__nocast-annotate-kmalloc_node.patch
> -rw-r--r-- akpm/akpm      3071 2005-07-26 00:37:34
> patches/mips-fbdev-kconfig-fix.patch
> -rw-r--r-- akpm/akpm      4097 2005-07-26 00:37:34
> patches/max_user_rt_prio-and-max_rt_prio-are-wrong.patch
> -rw-r--r-- akpm/akpm      2053 2005-07-26 00:39:53
> patches/md-when-resizing-an-array-we-need-to-update-resync_max_sectors-as-well-as-size.patch
> -rw-r--r-- akpm/akpm       946 2005-07-26 00:39:55
> patches/uml-readd-missing-define-to-arch-um-makefile-i386.patch


-- 
~Randy

Re: MM kernels - how to keep on the bleeding edge?

[Radoslaw AstralStorm Szkodzinski]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On Tue, 26 Jul 2005 16:35:21 -0700
Andrew Morton <akpm@osdl.org> wrote:

> 
> I did?
> 

Exactly, I did untar it and I already had a directory called patches.
Of course cleaning it up took no time, as fortunately I had no patches with
exactly the same name and no series file in the directory above,

-- 
AstralStorm

GPG Key ID = 0xD1F10BA2
GPG Key fingerprint = 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2
Please encrypt if you can.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MM kernels - how to keep on the bleeding edge?

[Andrew Morton]

Radoslaw "AstralStorm" Szkodzinski <astralstorm@gorzow.mm.pl> wrote:
>
> On Tue, 26 Jul 2005 16:35:21 -0700
> Andrew Morton <akpm@osdl.org> wrote:
> 
> > 
> > I did?
> > 
> 
> Exactly, I did untar it and I already had a directory called patches.
> Of course cleaning it up took no time, as fortunately I had no patches with
> exactly the same name and no series file in the directory above,
> 

hmm, I'll replace patches/ with broken-out/ to make those files the same as
the broken-out.tar.gz from -mm releases.

Re: MM kernels - how to keep on the bleeding edge?

[Michael Krufky]

Andrew Morton wrote:

>Michael Krufky <mkrufky@m1k.net> wrote:
>  
>
>>[ tracking mm stuff ]
>>    
>>
While we're on the topic of how -mm works, I have a question for you.  
How can I test a kernel source tree (during compilation) to determine 
whether it is a -mm tree or a -linus tree?

I will give you an example of what I am trying to do:

video4linux cvs is backwards compatible with older 2.6 kernels.  We keep 
backwards compatibility so that users can install newer device drivers 
without having to compile an entire kernel.  There are things like:

#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)

...all over the code that allows it to compile cleanly with many 
different versions.  Our patching scripts eliminate these "compatibility 
tests" from the source when building patches, and only presents the code 
compatible with the correct kernel version, so this doesn't interfere 
with development or the patching process.

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?

-- 
Michael Krufky

Re: MM kernels - how to keep on the bleeding edge?

[Michael Krufky]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

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>




[-- Attachment #2: mm-only.patch --]
[-- Type: text/plain, Size: 131 bytes --]

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

Re: MM kernels - how to keep on the bleeding edge?

[Andrew Morton]

Michael Krufky <mkrufky@m1k.net> wrote:
>
> Andrew Morton wrote:
> 
> >Michael Krufky <mkrufky@m1k.net> wrote:
> >  
> >
> >>[ tracking mm stuff ]
> >>    
> >>
> While we're on the topic of how -mm works, I have a question for you.  
> How can I test a kernel source tree (during compilation) to determine 
> whether it is a -mm tree or a -linus tree?
> 
> I will give you an example of what I am trying to do:
> 
> video4linux cvs is backwards compatible with older 2.6 kernels.  We keep 
> backwards compatibility so that users can install newer device drivers 
> without having to compile an entire kernel.  There are things like:
> 
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)
> 
> ...all over the code that allows it to compile cleanly with many 
> different versions.  Our patching scripts eliminate these "compatibility 
> tests" from the source when building patches, and only presents the code 
> compatible with the correct kernel version, so this doesn't interfere 
> with development or the patching process.

I'd really rather not have to get into that level of divergence.  Usually,
patches in -mm should be directly applicable to -linus.

> However, sometimes there are patches in -mm that are incompatable with 
> -linus.  An example of this is "Pavel's pm_message_t mangling" ... 

OK.  The way I handle an exceptional case like that is to merge the
-linus-compatible patch into -mm and then have another patch on top of that
which fixes things up for the -mm tree.  Later, that patch gets folded into
your patch if Pavel's stuff gets merged.  Or gets dropped if it doesn't get
merged.  Or gets folded into Pavel's stuff if your patch goes in first.

IOW: for a bunch of reasons we really do want to make the "fix up V4l for
-mm differences" patch be a separate patch file.

And I very much prefer that people work against -linus and when these
things occasionally pop up I'll just fix stuff up.  It's only if someone is
explicitly working against a patch which is only in -mm that they should
have to care about -mm vs -linus differences.

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

Well, if you really, really, really feel a need to do this then feel free
to send along a patch which does whatever you need it to do.

But as I say, I'd prefer that you be raising patches against -linus and
testing them in -mm.

Re: MM kernels - how to keep on the bleeding edge?

[Michael Krufky]

Andrew Morton wrote:

>Michael Krufky <mkrufky@m1k.net> wrote:
>  
>
>>However, sometimes there are patches in -mm that are incompatable with 
>>-linus.  An example of this is "Pavel's pm_message_t mangling" ... 
>>    
>>
>OK.  The way I handle an exceptional case like that is to merge the
>-linus-compatible patch into -mm and then have another patch on top of that
>which fixes things up for the -mm tree.  Later, that patch gets folded into
>your patch if Pavel's stuff gets merged.  Or gets dropped if it doesn't get
>merged.  Or gets folded into Pavel's stuff if your patch goes in first.
>
>IOW: for a bunch of reasons we really do want to make the "fix up V4l for
>-mm differences" patch be a separate patch file.
>
>And I very much prefer that people work against -linus and when these
>things occasionally pop up I'll just fix stuff up.  It's only if someone is
>explicitly working against a patch which is only in -mm that they should
>have to care about -mm vs -linus differences.
>
I think you may have misunderstood me here.  v4l didnt make the 
patches... You (akpm) did... We included them in our cvs when you merged 
them into -mm:

add-type-checking-to-pm_message_t-bttv-fix.patch added to -mm tree
add-type-checking-to-pm_message_t-tuner-core-fix.patch added to -mm tree
add-type-checking-to-pm_message_t-msp-fix.patch added to -mm tree
add-type-checking-to-pm_message_t-tda9887-fix.patch added to -mm tree

Trust me, nobody did anything wrong here, and everything that needs to 
be done with regards to this is already done, AFAIK.

I'm just saying it would be handy for the cvs to be able to compile 
separately with both -mm and -linus trees automatically.  I just sent 
you a patch that solves the issue.

-- 
Michael Krufky

Re: MM kernels - how to keep on the bleeding edge?

[Paul Jackson]

Andrew wrote:
> Ho hum.  Adding a "why
> this was dropped" to the email seemed too tricky.

I can't speak for all the other clue deprived gits out here, but for
me at least just adding a generic "If this patch was sent on to Linus,
that might be one possible reason it is now dropped from *-mm." boiler
plate sentence to the existing notice would have been sufficient to
calm my nerves and stop me from pestering you with stupid "what what
why did you kill my patch ?!?" queries.

No need for articial intelligence to condition the message on whether
the patch actually was sent to Linus, or not.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401