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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Mar 2014 18:05:54 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Greg KH <greg@...ah.com>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Mark Brown <broonie@...nel.org>,
	Stewart Smith <stewart@...ux.vnet.ibm.com>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the driver-core tree

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/