Re: [Ksummit-discuss] New CoC and Brendan Eich

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Josh,

On Fri, Oct 5, 2018 at 9:52 AM Josh Triplett <josh@joshtriplett.org> 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 <josh@joshtriplett.org> 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