Message-ID: <20150624131850.GA7346@gmail.com>
Date:	Wed, 24 Jun 2015 15:18:50 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Martin Steigerwald <martin@...htvoll.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Havoc Pennington <havoc.pennington@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Daniel Mack <daniel@...que.org>
Subject: Re: kdbus: to merge or not to merge?


* Martin Steigerwald <martin@...htvoll.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists