linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

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:	Wed, 29 Apr 2015 21:10:06 +0200
From:	Martin Steigerwald <martin@...htvoll.de>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	John Stoffel <john@...ffel.org>, Harald Hoyer <harald@...hat.com>,
	Richard Weinberger <richard.weinberger@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

Am Mittwoch, 29. April 2015, 13:39:42 schrieb Steven Rostedt:
> On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
> > If your customers wnat this feature, you're more than welcome to fork
> > the kernel and support it yourself.  Oh wait... Redhat does that
> > already.  So what's the problem?   Just put it into RHEL (which I use
> > I admit, along with Debian/Mint) and be done with it.
> 
> Red Hat tries very hard to push things upstream. It's policy is to not
> keep things for themselves, but always work with the community. That
> way, everyone benefits. Ideally, we should come up with a solution that
> works for all.

I think work with the community is a two-way process.

Two way as in actually really *listening* to feedback instead of trying to 
push things as much as possible, believing to be *right* about things. I 
honestly dislike the "I know it better than you, go away" kind of attitude 
I have seen again and again. Here, in systemd-devel (where I unsubscribed 
again as I saw no use in continuing the discussion there) and even in 
Debian mailinglists and bug reports.

Wherever I look what I call the "systemd" approach triggers intense 
polarity and resistance. With that I do not say there is something wrong 
about it, yet, I ask myself, why is that? And my best answer I came up 
with up to now comes back to how proponents of the new, different, not 
necessary better or worse, way, treat feedback.

There I found to some extent: taking the feedback into account and 
actually adressing it. Especially when the feedback fitted into the new way 
of doing things.

Yet I also found:

- "I know it better than you, go away."

- "Please only stick to pure technical reasons" as in "Whats wrong with 
the code?" disregarding any concerns about the *concept* and about 
different oppinions about whether kdbus code actually really belongs into 
the kernel

- Ignoring it

So I still say the issues are not purely technical. So I think a purely 
technical as in "what´s wrong with the code?" approach will not address 
the core of this discussion and the strong resistance against merging 
kdbus into the kernel.

It sometimes appears to me like childs arguing about whether to paint 
their favorite toy red or green. I think a healthy approach might be to 
agree to disagree and work from there. That would at least break the "I am 
right", "No, I am right" cycle.

Ciao,
-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/