On Thu, Apr 23, 2009 at 09:59:28AM -0400, Trond Myklebust wrote: > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote: > > > In any case, this patch does not belong in the NFS tree since it touches > > > generic library code, not NFS code. Benny, if nobody else wants to > > > shepherd it, then just send it directly to Linus. > > > > > That's a complete cop-out, if there had been no export at all how would > > you have proceeded? How is this situation any different? > > Please see Documentation/SubmittingPatches. If we were requesting a new > kernel feature, I'd go looking for the maintainer and get an ACK or get > said maintainer to include the patch in their tree. > > As it is, said kernel feature exists, but is broken. The correct thing > to do is to fix the kernel feature. Sooner, rather than later. > And until that feature is working, you have absolutely no business merging crap in to the kernel that uses it. You made an assumption that it was working, which turned out to be wrong (which you also failed to validate through any form of testing), and subsequently caused a regression. Mistakes happen and are expected in -next, refusing to deal with them at all on the other hand.. The first course of action any responsible maintainer would have taken would be to revert the offending changeset once the issue was pointed out until its dependencies were sorted out. Not only have you failed to do that, you couldn't even be bothered replying to the email with patch that pointed out the build failure in the first place. This created the mistaken conclusion that you were actually doing something about the regression you caused rather than just dismissing it out of hand. The nfs tree should be dropped on the floor immediately until this issue is resolved. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
