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

From: AstralStorm
Date: Tue Jul 26 2005 - 17:56:31 EST

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.)


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