Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752928AbbFXNTE (ORCPT ); Wed, 24 Jun 2015 09:19:04 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:36196 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753447AbbFXNSz (ORCPT ); Wed, 24 Jun 2015 09:18:55 -0400 Date: Wed, 24 Jun 2015 15:18:50 +0200 From: Ingo Molnar To: Martin Steigerwald Cc: Linus Torvalds , Andy Lutomirski , "linux-kernel@vger.kernel.org" , David Herrmann , Djalal Harouni , Greg KH , Havoc Pennington , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Daniel Mack Subject: Re: kdbus: to merge or not to merge? Message-ID: <20150624131850.GA7346@gmail.com> References: <20150624080502.GA23842@gmail.com> <6295881.qFxhe0B0Ak@merkaba> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6295881.qFxhe0B0Ak@merkaba> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3264 Lines: 65 * Martin Steigerwald wrote: > Am Mittwoch, 24. Juni 2015, 10:05:02 schrieb Ingo Molnar: > > > - Once one (or two) major distros go with kdbus, it becomes a de-facto ABI. > > If the ABI is bad then that distro will hurt from it regardless of whether we > > merge it upstream or not - so technical pressure is there to improve it. But > > if the kernel refuses to merge it, Linux users will get hurt > > disproportionately badly. The kernel not being the first mover with a new ABI > > is absolutely sensible. But once Linux distros have taken the initial > > (non-trivial) plunge, not merging a zero-cost ABI upstream becomes more like > > revenge and obstruction, which is not productive. The kernel has very little > > value without full user-space, after all, so within reason the kernel project > > has to own up to distro ABI mistakes as well. > > So, in order to merge something that is not accepted upstream yet, is it an > accepted way to encourage distros to use it nonetheless, to get it upstream then > anyway as in "as, look, now this and this distro uses it"? > > When I read > > > Not because I like it so much, but because I think the merge process should be > > stripped of politics and emotion as much as possible: if an initial submission > > is good and addresses all technical review properly, and if the cost to the > > core kernel is low, then barring alternative, fully equivalent and superior > > patch submissions, rejecting it does more harm than good. > > I think you didn?t mean it that way, as you state proper technical review as a > requirement. > > Can you clarify? There's no conflict: when merging something upstream, technical feedback has to be addressed. AFAICS that is what happened when we merged controversial bits in the past where Linux distros jumped the gun: such as AppArmor or Binder. The main question that gets eliminated by a major distro using something is the (important) question of: 'does the Linux kernel need an ABI like that?'. Distros still run a considerable risk when forking new ABIs, obviously - as 'pre release' ABIs rarely survive upstreaming, and there's no guarantee that it will be accepted upstream. > Still as far as I got it, Andy raised technical concerns which Greg outrightly > rejected as invalid without any further explaination. That does not seem like > technical concerns have been properly addressed to me. I haven't seen such responses but maybe I haven't managed to dig deep enough into the rather sizable discussion. Not addressing valid technical feedback would be a first for Greg in my book, so he definitely deserves the benefit of doubt from me. And the thing is, in hindsight, after such huge flamewars, years down the line, almost never do I see the following question asked: 'what were we thinking merging that crap??'. If any question arises it's usually along the lines of: 'what was the big fuss about?'. So I think by and large the process works. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/