On Fri, Apr 24, 2009 at 01:50:25PM -0400, Christoph Hellwig wrote: > Having a working tree for debugging stuff is fine, but the point is > that it should never be pulled into mainline and probably frequently > reabsed to avoid cruft. In that case there's really no point in > creating branches to share pieces of tree history, just apply the patch > locally if you think you want it and merge or rebase once mainline gets > the patch. > > Al frequently rebases the vfs tree, btw - so even if it was a separate > branch now there's a fair chance it would end up in mainline with a > different commit id. Nah, it's not that. I can hold that in a separate branch and keep it anchored. The question is, what else will end up there? * the work inside the methods on BKL _removal_ * things like merging that ->write_super() call into ->put_super(), etc. * probably parts of work on s_flags mess and ro (tied to remout) I agree that getting rid of BKL in that area is a good thing; no arguments about that. If it had been entirely self-contained, I'd gladly drop that stuff into a separate branch, let mingo pull it and forgot about the entire thing. The things get tricky, though, since we have two more things in the same area: remount (once Nick comes back with the latest on mnt_write_count, I'm going to merge that and start on per-sb side, BTW) and stuff around Jan's sync series. So let's figure out how do we do that. I have no problem with a single branch for *all* of that, separate from the rest of VFS stuff. However, I very much suspect that it's not what mingo et.al. have in mind - too much stuff alien for them. I can keep a cherry-picked branch with minimal BKL-affecting backports from that one. It might or might not be OK, depending on what the hell their workflow is in -tip. I honestly have no idea how the devil the things are done there, except that it apparently involves much more merges than I'd be comfortable with, but then I never had a taste for literal clusterf*cks either. Could the folks from the other side tell * what kind of patches do they want in that branch * what kind of patches can they accept in that branch * when do they intend to see it merged into mainline * how much is going to be merged on top of that and how often (if ever) is it going to be thrown out and re-pulled. I.e. is that for a devel/debugging tree pulled together from many topic branches on regular basis, with branches dropped/re-added/etc. (i.e. something a-la linux-next) or is that something more cast in stone? Seriously, let's sort that out; flamefests being what they are, there's a real problem with keeping two streams of development tolerable for participants. I *do* have very unkind words to say to Ingo, but that's a matter for private mail and I'm not going to let that anywhere near development question. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
