linux-kernel - Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

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:   Thu, 1 Nov 2018 14:11:53 -0700
From:   Josh Triplett <josh@...htriplett.org>
To:     "Paul E. McKenney" <paulmck@...ux.ibm.com>
Cc:     NeilBrown <neil@...wn.name>, Mishi Choudhary <mishi@...ux.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        ksummit-discuss@...ts.linuxfoundation.org
Subject: Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of
 Conduct: Fix some wording, and add an interpretation document

On Thu, Nov 01, 2018 at 09:45:44AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
> > Not when that document started out effectively saying, in an elaborate
> > way, "code > people".
> 
> Interesting.
> 
> I am curious what leads you to your "code > people" statement.  Of course,
> one could argue that this does not really matter given that the code of
> conflict is no longer.  However, I would like to understand for future
> reference, if for no other reason.
> 
> One possibility is that you are restricting the "people" to only those
> people directly contributing in one way or another.  But those using the
> kernel (both directly and indirectly) are important as well, and it is
> exactly this group that is served by "the most robust operating system
> kernel ever", the chest-beating sentiment notwithstanding.  Which is in
> fact why I must reject (or rework or whatever) any patch that might result
> in too-short RCU grace periods:  The needs of the patch's submitter are
> quite emphatically outweighed by the needs of the kernel's many users,
> and many of the various technical requirements and restrictions are in
> fact proxies for the needs of these users.

As discussed in many other places as well, nobody is suggesting at all
that the standards for accepting code should change. Reject the patches
you would have rejected, accept the patches you would have accepted. All
of this affects *communication*.

- Josh Triplett