On 05/25/2010 11:14 PM, Dean Hildebrand wrote: > > >> >> I can send some post_submit patches with the code ifdef'ed out if people would be content with that. >> > > Thanks for the background. I would be much happier if you sent patches > with the code ifdef'd out, added with the comment in the code regarding > which patches you believe introduced the problem. > > Dean >> Fred I disagree. Source code is not a version management system. We have git for that. The code is never lost it is there for eternity in the git tree. We could ask Benny to tag the last branch that had broken directIO as LAST_directIO_VERSION for easy random access at future time. If in the future someone smart wants to forward port the code and fix it then the *right* way to do it is by manual octopus merge at the point of branch. Never, Never uncomment out code that was sitting collecting dust. Manual octopus merge I mean using the two diffs from the two sides of the branch, and replaying one on the other. For instance if at one patch a function was moved, then redo the move of the current function again, not leave the old code as it was before. Let the merge point out the points of friction. Because you see, with commented code, there is never a merge conflict it will always uncomment. And anyway the Kernel people will never accept code in comments. There are out-of-tree gits to do that. So I don't even think it is an option. The pnfs branches are patches that should eventually go upstream. Or are currently the only option for the testing of upstream code. Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
