From: Willy Tarreau <w@1wt.eu>
To: Sean <seanlkml@sympatico.ca>
Cc: Andi Kleen <ak@suse.de>,
davej@redhat.com, pageexec@freemail.hu,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] exception processing in early boot
Date: Wed, 30 Aug 2006 15:46:44 +0200 [thread overview]
Message-ID: <20060830134644.GA20129@1wt.eu> (raw)
In-Reply-To: <20060830100015.6b967c32.seanlkml@sympatico.ca>
On Wed, Aug 30, 2006 at 10:00:15AM -0400, Sean wrote:
> On Wed, 30 Aug 2006 15:16:12 +0200
> Willy Tarreau <w@1wt.eu> wrote:
>
> > That's already what I'm doing, and yes, it is *that* hard. We're literally
> > speaking about *thousands* of patches. It's as difficult to find one patch
> > within 2.6 git changes as it is to find a useful mail in the middle of 99%
> > spam. This is not because of GIT but because of the number of changes.
>
> Willy,
>
> The git-cherry command might be useful for you in this situation. It will
> show you all the patches in one branch that have been merged in an upstream
> branch, and those that haven't. Not sure if it's perfect for your situation,
> but may be worth a look.
I've already used it (it's what I was using when to maintain the 2.4-hf
tree in parallel to Marcelo's mainline). But it's useful when you have
*a few* patches. I'm really speaking about *thousands* of patches that
get merged into 2.6 every few months and this is what makes the job difficult.
Not to mention that they also get merged in 2.6-mm in advance, or that
sometimes they are obsoleted and/or replaced by something else.
Clearly, I'm not going to track all 2.6 patch by patch to maintain 2.4 !
The most scalable workflow is distributed, and should be oriented towards
push and not pull. We just have to ensure that *someone* takes care of
each patch and tracks it up to its merge.
> Sean
Cheers,
Willy
next prev parent reply other threads:[~2006-08-30 14:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-30 6:39 [PATCH][RFC] exception processing in early boot Willy Tarreau
2006-08-30 9:51 ` Andi Kleen
2006-08-30 12:18 ` Willy Tarreau
2006-08-30 12:59 ` Andi Kleen
2006-08-30 13:16 ` Willy Tarreau
2006-08-30 14:00 ` Sean
2006-08-30 13:46 ` Willy Tarreau [this message]
2006-08-30 14:00 ` Sean
[not found] ` <44F5D81A.9650.5BE48F99@pageexec.freemail.hu>
2006-08-30 16:30 ` Andi Kleen
2006-08-30 16:59 ` linux-os (Dick Johnson)
2006-08-30 17:02 ` Andi Kleen
2006-08-30 17:15 ` linux-os (Dick Johnson)
[not found] ` <44F5E818.20898.5C230A79@pageexec.freemail.hu>
2006-08-30 17:52 ` Andi Kleen
[not found] ` <44F5F348.1251.5C4EBCCB@pageexec.freemail.hu>
2006-08-30 18:26 ` Andi Kleen
2006-08-30 19:01 ` Willy Tarreau
2006-08-30 19:36 ` Andi Kleen
2006-08-30 20:03 ` Willy Tarreau
2006-08-30 20:06 ` Andi Kleen
2006-08-30 20:40 ` Willy Tarreau
2006-08-30 21:31 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2006-08-31 2:05 Chuck Ebbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060830134644.GA20129@1wt.eu \
--to=w@1wt.eu \
--cc=ak@suse.de \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pageexec@freemail.hu \
--cc=seanlkml@sympatico.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.