Hello, On Mon, Mar 17, 2014 at 02:56:19PM -0700, Greg KH wrote: > > Now regarding the practicals of sorting out our trees, Stephen suggested > > that rather than doing anything on my side (heh, I like that !), you > > should revert the last patch of the series, the one removing the old > > API, in your tree. > > > > It can then be re-applied later around rc1. > > I'll look to see if we can do that, let me dig it up out of my tree... I think this is being blown out of proportion. It was a rarely used API and converting to the new one is mostly trivial which can be easily done as a merge fix, which is what it is. Seriously, following protocols is beneficial upto certain point but we don't want DMV level beaurocracy in handling patches and there's something wrong when the first questions for merge conflict in devel branches which comes up are not "what's this change and what would it take to resolve it?" but those of strict adherences to protocol. Can we please take a step back and look at what we're doing? This was a change of API which was used very obscure and haven't seen new users for years. It is well within the scope of normal (and efficient) patch routing to route it directly without separate staging release. It sure developed a conflict but there's nothing wrong to that. We don't even want to try to eliminate all the conflicts. That'd be a lot of extra effort for no actual gain and simply a stupid trade-off. This is a merge conflict well with in the scope of what we can expect to happen with distributed development and this whole thing works as well as it does only because we can make *sensible* trade offs not only in code itself but also in how we resolve conflicts among different branches. Thanks. -- tejun -- 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
