On Fri, Sep 9, 2011 at 1:48 PM, Julia Lawall <julia@xxxxxxx> 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 linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
