lkml.org 
[lkml]   [2018]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2018-11-02 14:14    [W:0.125 / U:1.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site