ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Jonathan Corbet <corbet@lwn.net>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] New CoC and Brendan Eich
Date: Fri, 5 Oct 2018 12:03:14 -0400	[thread overview]
Message-ID: <20181005160314.GA20342@thunk.org> (raw)
In-Reply-To: <20181004160414.20c72c21@lwn.net>

On Thu, Oct 04, 2018 at 04:04:14PM -0600, Jonathan Corbet wrote:
> Again, I don't think anybody is envisioning telling maintainers that they
> cannot accept patches from a given individual over conduct issues, and
> I've certainly heard no talk of trying to mandate email filters.  I don't
> understand who you think might be telling the maintainer not to apply such
> a patch..?
> 
> One fairly common approach to conduct problems is to have the person
> involved work through somebody who is willing to deal with them for a
> while.  This sounds kind of like that sort of scenario.
> 
> The community needs to figure out how it wants to handle the disciplinary
> side of things should we ever have a case where trying to talk to the
> person involved isn't enough.  I suppose that *could* involve a blanket
> refusal to accept that person's patches under any circumstances, but I
> don't think I've ever seen that in the past except in cases where there
> were issues with the patches themselves.  I would be surprised to see that
> change.

It might be helpful to consider that cutting off a contributor has
happened already, when the netfilter core team, as maintainers,
collectively made a decision to not accept any patches from a
copyright troll.  Neither Linus, nor the TAB, nor the LF were involved
in that decision.  That maintainer team decided to do that on their
own.  The sky didn't fall down.  No one sued the netfilter core team
for millions and millions of dollars.  In fact, it seems to me that
the community as a whole breathed a sign of relief, and we all moved
on.

I don't know what the netfilter core team would decide to do if the
copyright troll submitted a security patch.  It wouldn't be up to me,
but if they asked them for my advice, I'd tell them they received a
bug report, and they should fix it.  In this particular case, I'd
advise them to find a different way to fix the bug, and rewrite it in
a clean room fashion, because, you know --- copyright troll --- but I
don't think it's worth it to figure out how to handle every single
eventuality ahead of time.

Like most personnel matters, it's going to be very case specific, but
it should be noted that the decision to cut off contributions from the
copyright troll happened after much provocation.  It was *not*
something that was done casually, and I'm sure there was a lot careful
thought, and probably emtional anguish, involved.

People seem to be assuming that this kind of very extreme decision
happen casually and easily, but it's happened only *once* in over a
quarter century of Linux kernel development.  And it only got done
after **substantial** damage had already been inflicted, and it was
the only way to protect the community.

	  	    	   	       	      - Ted

  reply	other threads:[~2018-10-05 16:03 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-04 16:23 jonsmirl
2018-10-04 18:33 ` Laurent Pinchart
2018-10-04 19:05   ` jonsmirl
2018-10-04 19:21     ` Rodrigo Vivi
2018-10-04 19:53       ` jonsmirl
2018-10-05  7:21       ` Geert Uytterhoeven
2018-10-08 21:35       ` Mauro Carvalho Chehab
2018-10-08 23:20         ` Rodrigo Vivi
2018-10-09 10:07           ` Mauro Carvalho Chehab
2018-10-09 15:59             ` Rodrigo Vivi
2018-10-09 16:52             ` Chris Mason
2018-10-09 22:03               ` Dan Williams
2018-10-10  6:47                 ` Geert Uytterhoeven
2018-10-10 13:57                   ` Mauro Carvalho Chehab
2018-10-10 17:21                     ` Josh Triplett
2018-10-10 18:28                       ` Mauro Carvalho Chehab
2018-10-10 19:56                         ` Josh Triplett
2018-10-10 20:12                           ` Mauro Carvalho Chehab
2018-10-10 20:17                             ` Josh Triplett
2018-10-04 19:34     ` Laurent Pinchart
2018-10-04 20:39   ` Al Viro
2018-10-04 20:56     ` Jonathan Corbet
2018-10-04 21:27       ` Thomas Gleixner
2018-10-04 22:04         ` Jonathan Corbet
2018-10-05 16:03           ` Theodore Y. Ts'o [this message]
2018-10-04 22:05         ` Tim.Bird
2018-10-05  6:23           ` Christoph Hellwig
2018-10-05  7:12       ` Geert Uytterhoeven
2018-10-05  7:50         ` Josh Triplett
2018-10-05  9:20           ` Jani Nikula
2018-10-05  9:57             ` Laurent Pinchart
2018-10-05 10:45               ` Joe Perches
2018-10-05 10:55                 ` Laurent Pinchart
2018-10-05 12:59               ` Jani Nikula
2018-10-05 13:09                 ` Laurent Pinchart
2018-10-05 15:17                 ` James Bottomley
2018-10-05 18:28                   ` Josh Triplett
2018-10-05 18:39                     ` James Bottomley
2018-10-04 20:57     ` Josh Triplett
2018-10-05  7:16       ` Geert Uytterhoeven
2018-10-05  7:51         ` Josh Triplett
2018-10-05  8:00           ` Geert Uytterhoeven
2018-10-05  8:44             ` Josh Triplett
2018-10-05 15:26           ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181005160314.GA20342@thunk.org \
    --to=tytso@mit.edu \
    --cc=corbet@lwn.net \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox