> > > also, if the upstream > > > changes touch code that conflicts with a backport > > > patch, you get to fix the problem as it happens > > > > That's exactly the thing that I do not want to do. > > you don't want to know about a problem a patch > until days or weeks later when the auto build > keeps failing and you don't know why? it is > easy to catch many problems _before_ the build > check fails...
I don't work this way. I just just apply all patches before pushing out. And I see *immediately* the patch that conflicts - unlike merge conflict where I will know which file conflicts but not which change created the conflict. And if a patch conflicts with upstream code, an option to move the patch aside and defer the merge decision to patch author is very important to me: this just happened with ehca backport and update to 2.6.23-rc1. I do not want to delay update to 2.6.23-rc1 until IBM can be bothered to update their backport. Yes, this means that the specific module won't build on a specific kernel until the conflict is resolved. But there are multiple conflicts and each needs to be resolved by another person. -- MST _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg