On Mon, 2008-02-11 at 21:53 -0800, Greg KH wrote: > > this is why you need specific trees for just the API change, and these > > need to EXPLICITLY go first before EVERYTHING ELSE. Yes this needs a > > bit of coordination, but it's the only way. > > Even then, it will not work. > > Again, Roland isn't going to want to always pull in my driver tree just > to build his tree. He wants to, and needs to do his own development > effort. > > But when we merge them together, there would be problems. > > So, you can't just "drop" the IB tree. > You can't just "drip" my tree. > > Where do you "fix this up" at? I can send a patch for the IB tree, but > Roland can't put it in his tree, and I can't put it in my tree, it needs > to go _after_ both of our trees. Actually, we had exactly this issue with the SCSI bidirectional patches: They depended on the sg_table patches in block. The solution I adopted was two merge trees: One to go in immediately with no dependencies (scsi-misc-2.6) and the other based on the pieces of block (so it would compile and apply) to go in mid way through the merge round after block (scsi-bidi-2.6). What I did was keep rebasing the bidi tree until I could see there was nothing other than a plane base before merging it. Of course, this only worked because Jens has a git tree ... it would have been a lot harder (but not impossible) if I'd had entangled patches from a quilt tree. So I've already proven that the split tree solution is viable, if not pretty. The bidi tree had to be rebased an awful lot as the block trees changed and rebased. Unfortunately, git isn't very good at this, I eventually had to keep a base and a top reference and just try to cherry pick this series into the new constructed block tree. But it can be done... > That's what -mm has been able to handle so far, and that needs to also > work with -next. Actually, we never successfully got block and bidi via -mm. James - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
