On Fri, 9 Sep 2011, Luis R. Rodriguez wrote: > 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? Sorry. The + code. The #ifdefs ad the compatibility code. We don't have to interpret it, so we don't care whether it is only related to kernel version numbers or something more complex. julia > > 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 >
