Re: kdbus: to merge or not to merge?

[Martin Steigerwald]

Am Dienstag, 23. Juni 2015, 11:25:49 schrieb Martin Steigerwald:
> Am Dienstag, 23. Juni 2015, 09:22:40 schrieb Richard Weinberger:
> > On Tue, Jun 23, 2015 at 8:41 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
> 
> wrote:
> > >> The current state of uncertainty is problematic, I think.  The kdbus
> > >> team is spending a lot of time making things compatible with kdbus,
> > >> and the latest systemd release makes kdbus userspace support
> > >> mandatory.
> > > 
> > > I stopped here in this email, as this is just flat out totally wrong,
> > > and I don't want to waste my time trying to refute other totally wrong
> > > statements as that would just somehow give them some validation that
> > > they could possibly be correct.
> > 
> > For the guys who not follow systemd development, this is the
> > announcement in question:
> > http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.htm
> > l
> > 
> >         * kdbus support is no longer compile-time optional. It is now
> >         
> >           always built-in. However, it can still be disabled at
> >           runtime using the kdbus=0 kernel command line setting, and
> >           that setting may be changed to default to off, by specifying
> >           --disable-kdbus at build-time. Note though that the kernel
> >           command line setting has no effect if the kdbus.ko kernel
> >           module is not installed, in which case kdbus is (obviously)
> >           also disabled. We encourage all downstream distributions to
> >           begin testing kdbus by adding it to the kernel images in the
> >           development distributions, and leaving kdbus support in
> >           systemd enabled.
> > 
> > Now kdbus is opt-out instead of opt-in.
> > Although I didn't test it so far, systemd should work just fine if
> > kdbus is not present
> > as it can fall back to dbus.
> 
> Andy, I think it was partly this what triggered your mail. I wrote a mail
> about asking for a careful review of dbus exactly due to this some days
> ago, but didnÂt include any Ccs.
> 
> In that I wrote:
> 
> -------------------------------------------------------------------------
> I hope you kernel developers will still review kdbus carefully as you did
> so far, instead of giving in to any downstream pressure by distros.
> 
> It is exactly this attitude and this approach of systemd upstream that I
> feel uneasy about. Instead of humbly waiting and working towards having
> kdbus accepted to the kernel, systemd developers seem to use any means to
> create indirect pressure to have it included eventually.
> 
> I hope that it will still be technical excellence as entry barrier for
> anything that goes into the kernel.
> 
> Please note: I do not judge upon the technical quality of kdbus. I think
> others are more knowledgeable to do it.
> -------------------------------------------------------------------------
> 
> I think the move of systemd developers is able to create downstream
> pressure to include kdbus into the kernel and AndyÂs mail is partly a
> reaction to that.
> 
> I personally wouldnÂt ask for it not to be included into the kernel, but I
> just ask for a careful review instead of giving in to any downstream
> pressure the move of systemd developers may trigger.
> 
> But unlike Andy I did not review kdbus for technical quality. It seems
> that Andy has strong technical concerns about it. But you Greg, write
> that these are not correct without any explaination on why you think this
> is so. You outrightly write that these are invalid without any
> explaination at all.
> 
> Greg, if you do not want any preemptive decision not to merge kdbus before
> your next pull request, I kindly also ask for for no preemptive decision
> to actually merge it then, as it may be included in Fedora or other
> distro kernels already. Having it in distros can be good for testing
> things, but it does not necessarily say anything about technical
> qualification of the patches for the upstream kernel. So no argument like
> in "but, look, its in the distros" in my view is enough reason to merge
> it into the upstream kernel.
> 
> On the next time you do your pull request, if Andy or anyone else posts
> technical concerns, for a careful review process I think it is important
> that you or someone else actually addresses them instead of just telling
> that these are invalid (in your point of view!).
> 
> Cause this is exactly again an attitude I found with systemd upstream. "I
> am right, you are wrong, go away". It is this kind of attitude â I have
> seen it on both sides of this discussion â that creates most of the
> friction and energy blockage and polarity around this topic. I tried to
> bring this up in systemd-devel once, but in the end I unsubscribed after
> having been called "being a dick" there. From Lennart himself who on the
> other hand whines about perceived rudeness in kernel community.

Let me take some judgement out of what I wrote and have an attempt to 
describe instead:

>From Lennart himself who on the other hand complains about what he perceives 
as (my wording from memory of his Google Plus post) rudeness in kernel 
community.

> So again I ask: What is it what you actually want to create? And how can
> you create it (instead of creating something, like this friction and
> energy blockage, that you probably didnÂt want to create at all)? I ask
> this to anyone involved.
> 
> Thank you,

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/