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