ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] New CoC and Brendan Eich
Date: Thu, 4 Oct 2018 16:04:14 -0600	[thread overview]
Message-ID: <20181004160414.20c72c21@lwn.net> (raw)
In-Reply-To: <alpine.DEB.2.21.1810042323350.29948@nanos.tec.linutronix.de>

On Thu, 4 Oct 2018 23:27:33 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 4 Oct 2018, Jonathan Corbet wrote:
> > On Thu, 4 Oct 2018 21:39:57 +0100
> > Al Viro <viro@ZenIV.linux.org.uk> wrote:
> >   
> > > 	* contributor Alice gets banned from contributing, for whatever reason
> > > 	* Alice finds a roothole and posts a technically valid fix
> > > 	* maintainer Bob sees the posting, verifies that the bug is real, that
> > > the fix is correct and that the source of that patch is banned.  
> > 
> > So, while remedies under the CoC are yet to be determined in any sort of
> > detail, I don't believe I have heard anybody talk about banning the
> > acceptance of patches from anybody.  Speaking only for myself, I have a
> > hard time seeing that happening in the absence of other sorts of concerns
> > (the event where a would-be contributor started sending under a sock
> > puppet name because nobody would consider his work anymore comes to mind).
> > 
> > What *is* common under CoCs in various projects is banning from specific
> > fora, such as this mailing list.  But that is a different thing and
> > doesn't bring about the scenario described above.  
> 
> It does. Alice is banned from the mailing list, but still posts the
> roothole fix to LKML and Cc's the maintainer according to the rules. LKML
> drops the post, but the maintainer still gets it. Now what is he supposed
> to do? Ignore it, because he forgot to add Alice to his /dev/null filter?

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.

In any case, this scenario is one thing to keep in mind as we work all
this out.

jon

  reply	other threads:[~2018-10-04 22:04 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 [this message]
2018-10-05 16:03           ` Theodore Y. Ts'o
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=20181004160414.20c72c21@lwn.net \
    --to=corbet@lwn.net \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=tglx@linutronix.de \
    /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