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

[AstralStorm]

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

> Michael Krufky <mkrufky@xxxxxxx> 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: pgp00000.pgp
Description: PGP signature