[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Sep 2011 14:13:59 -0700
From: "Luis R. Rodriguez" <mcgrof@...il.com>
To: Julia Lawall <julia@...u.dk>
Cc: Jesper Andersen <jespera@...u.dk>,
Hauke Mehrtens <hauke@...ke-m.de>,
linux-wireless <linux-wireless@...r.kernel.org>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Backporting the Linux kernel, for good - was: Re: semantic patch inference
On Fri, Sep 9, 2011 at 1:48 PM, Julia Lawall <julia@...u.dk> wrote:
> Thanks for your email. It made me realize that there was one thing that I
> didn't understand at all. If the patches are only intended to apply to
> linux-next, that makes the problem quite a bit simpler.
Awesome, and yes the patches/ are only targeted at applying onto
linux-next.git. When Linus decides to merge and out 3.x-rc1 I simply
then set $GIT_TREE to $HOME/linux-2.6-allstable/ and run the script to
suck code from there and apply patches from there.Turns out that
because the effort was done on linux-next and because linux-next will
look very much like what Linus ends up merging the patches/ will still
apply. So what I do then is simply create a branch for that target
stable kernel and keep refreshing the patches for that stable kernel
on that branch -- while the master branch keeps chugging along with
linux-next.
> I guess that the patch that spdiff will receive will already contain the
> appropriate #ifs, so we don't have to be concerned about them.
That is correct.
> We just add them in as is.
I do not follow, add what?
> There was also the question about one or multiple types of changes. I
> think this is not a problem, but Jesper should confirm. If a patch contains
> two changes and one can be generalized and the other one cannot for some
> reason, does spdiff give up on the whole thing, or does it do what it can?
>
> Overall, the whole thing seems to be doable :)
Wow. I'm thrilled, so say the least.
Luis
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists