All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] New CoC and Brendan Eich
Date: Thu, 4 Oct 2018 13:57:37 -0700	[thread overview]
Message-ID: <20181004205648.GB10640@localhost> (raw)
In-Reply-To: <20181004203956.GR32577@ZenIV.linux.org.uk>

On Thu, Oct 04, 2018 at 09:39:57PM +0100, Al Viro wrote:
> On Thu, Oct 04, 2018 at 09:33:15PM +0300, Laurent Pinchart 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.
> 
> What should Bob do?  Discuss.

(Presumably they "post" that to some place that isn't part of the Linux
kernel community, such as a security research group. Also, let's leave
aside that the above scenario would come after some non-trivial
likely-private discussion with them, in which they refused to meet the
standards expected of the kernel community; standing reminder that bans
aren't typically step 1 of a process.)

What do you do when a patch is posted that fixes a real bug but doesn't
meet patch requirements in other ways? I've seen developers fix up such
patches themselves, with varying degrees of effort required; I've also
seen developers reject such patches with a request to fix, and other
people coming along to clean up the same fix. See also grsecurity
patches.

What do you do if some random downstream kernel branch (e.g. a distro or
vendor kernel) has a useful patch, and you don't expect the person who
wrote it to contribute it upstream, but it still has a signoff and
you're willing to do the work yourself?

In general: verify that the patch works, still has the right license,
has a signoff, etc. (If someone is being particularly vindictive and
putting irrelevant things in commit messages, etc, then those can easily
be removed; OTOH, if someone has a patch and doesn't provide a signoff,
that'd be an orthogonal problem that isn't specific to this situation,
as you couldn't assume you could incorporate the patch.) Then apply the
patch as a fix, and include it in their next pull request upstream.

Roughly speaking, I'd treat that situation the same as "what if someone
has a patch that's otherwise entirely correct, and a now non-functional
email address that bounces, with no way to reach them", and proceed
accordingly.

  parent reply	other threads:[~2018-10-04 20:57 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-04 16:23 [Ksummit-discuss] New CoC and Brendan Eich 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
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 [this message]
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=20181004205648.GB10640@localhost \
    --to=josh@joshtriplett.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.