David Howells <dhowells@xxxxxxxxxx> wrote: > > Andrew Morton <akpm@xxxxxxxx> wrote: > > > The number of rejects gets into the "I'm not confident it'll work after > > this" territory. > > > > Here's Trond's current diff: > > I assume this is you applying these patches to your -mm tree (which contains > some of Trond's patches), rather than Linus's tree or Trond's tree. Why do you assume that? I guess I have some smallish NFS changes apart from git-nfs.patch, but the great bulk of the skew is due to Trond's pending stuff. > Can you be more specific about which patches you've got problems with? Is it > mainly that patch 5/5 and little bits of patch 2/5 don't apply? Seems that way. nfs-apply-mount-root-dentry-override-to-filesystems: 3 out of 10 hunks FAILED -- saving rejects to file fs/nfs/inode.c.rej nfs-unify-nfs-superblocks-per-protocol-per-server: 5 out of 18 hunks FAILED -- saving rejects to file fs/nfs/inode.c.rej 1 out of 2 hunks FAILED -- saving rejects to file fs/nfs/nfs4proc.c.rej 1 out of 1 hunk FAILED -- saving rejects to file include/linux/nfs_fs_sb.h.rej > There's a problem here in that your tree is incompatible with Linus's tree in > various ways. I believe you've said before that you prefer the patches you're > given to have been made against Linus's tree... is that right? Ordinarily, yes. But for something like this you should work against the NFS development tree, not against mainline. It's pretty unlikely that Trond would want to preempt already-queued things with new work. All the patches in -mm which affect the subsystem trees are already based on those subsystem trees, because that's how they'll find their way to mainline. So I'd suggest that you base this work on git://git.linux-nfs.org/pub/linux/nfs-2.6.git (Trond, please correct me if that's not appropriate). If there are a few nfs-related things only in -mm which conflict with that, I'll sort them out. > Also, do you yet have a git tree holding your patchset? Nope - just the releases at git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git. > If not, have you > considered using stacked git (StGIT) to provide one? The problem is that the -mm patches often don't even apply, let alone compile, let alone run. It takes 6-8 hours to get it all stabilised, fixed and tested and as soon as that window closes it's all broken again. If I made that lot available in realtime I don't think it'd be much use to anyone and would be a net time-waster. Which is why I encourage developers to develop against mainline. Except in this case that's not appropriate - you should develop against the relevant subsystem tree.
