From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C6756F40 for ; Fri, 5 Oct 2018 08:00:26 +0000 (UTC) Received: from mail-ua1-f66.google.com (mail-ua1-f66.google.com [209.85.222.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1FCF5773 for ; Fri, 5 Oct 2018 08:00:24 +0000 (UTC) Received: by mail-ua1-f66.google.com with SMTP id g18-v6so4381498uam.6 for ; Fri, 05 Oct 2018 01:00:24 -0700 (PDT) MIME-Version: 1.0 References: <6108593.JtmfA2IdsK@avalon> <20181004203956.GR32577@ZenIV.linux.org.uk> <20181004205648.GB10640@localhost> <20181005075156.GB24138@localhost> In-Reply-To: <20181005075156.GB24138@localhost> From: Geert Uytterhoeven Date: Fri, 5 Oct 2018 10:00:11 +0200 Message-ID: To: Josh Triplett Content-Type: text/plain; charset="UTF-8" Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] New CoC and Brendan Eich List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Josh, On Fri, Oct 5, 2018 at 9:52 AM Josh Triplett wrote: > On Fri, Oct 05, 2018 at 09:16:06AM +0200, Geert Uytterhoeven wrote: > > On Thu, Oct 4, 2018 at 10:58 PM Josh Triplett wrote: > > > 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. > > > > It's not exactly the same: for the non-functional email address, you can > > still fix the issue yourself with a "Reported-by" line, without violating the > > rule about publishing addresses, as the address is no longer valid. > > That wasn't the situation as proposed; the situation as proposed > involved a patch already written. (And the email address issue was I agree it's not 100% the same. What do you do now, if someone sends a patch fixing a critical issue, but the patch is not up to your standards as a maintainer, and the submitter runs away, and never follows up? > already discussed; an email address attached to a publically posted > patch is hardly private information.) Which you cannot publish as the person was banned? Just stripping the banned person's name is also not a solution, as that would be willful copyright violation. Summary: banning persons from contributing opens a new can of worms. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds