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:   Fri, 2 Nov 2018 06:13:11 -0700
From:   "Paul E. McKenney" <paulmck@...ux.ibm.com>
To:     Josh Triplett <josh@...htriplett.org>
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 02:11:53PM -0700, Josh Triplett wrote:
> 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.

There have been a great many discussions in a great many places expressing
a great many views, but it is good to hear your view on this particular
point.  It should come as no surprise that I advise you in the strongest
possible terms to continue with the view that standards for accepting code
into the Linux kernel should not decrease.

>                                                                      All
> of this affects *communication*.

Communication is inherently difficult.  As I suspect the two of us just
demonstrated.  ;-)

							Thanx, Paul