Re: linux-next: build failure after merge of the driver-core tree

[Tejun Heo <tj@kernel.org>]

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