All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Theodore Ts'o <tytso@mit.edu>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	ksummit@lists.linux.dev, linux-fsdevel@vger.kernel.org
Subject: Re: [MAINTAINER SUMMIT] Adding more formality around feature inclusion and ejection
Date: Fri, 22 Aug 2025 13:29:43 +0200	[thread overview]
Message-ID: <20250822132943.1ca76a8a@foz.lan> (raw)
In-Reply-To: <aKeb8vf2OsOI19NA@casper.infradead.org>

Em Thu, 21 Aug 2025 23:21:38 +0100
Matthew Wilcox <willy@infradead.org> escreveu:

> On Thu, Aug 21, 2025 at 04:34:07PM -0400, Theodore Ts'o wrote:
> > There is the saying that "bad facts make bad law", and the specifics
> > of this most recent controversy are especially challenging.  I would
> > urge caution before trying to create a complex set of policies and
> > mechanim when we've only had one such corner case in over 35 years.  
> 
> Well. we may have dodged a few bullets before now.  Just in filesystems,
> I can think of Hans Reiser, Jeff Merkey, Boaz Harrosh, Daniel Phillips
> (no, i'm not saying any of the others did anything as heinous as Hans,
> but they were all pretty disastrous in their own ways).

There are other cases as well: there was a media driver maintainer that
did pretty bad things, including physical threats against other
maintainers. I even got a report that he did threat to life another
maintainer who complained he would be violating GPL copyrights.

> I don't think we can necessarily generalise from these examples to,
> say, Lustre.  That has its own unique challenges, and I don't think that
> making them do more paperwork will be helpful.

Agreed. I don't think those few examples have much in common:
each had different types of issues. So, I don't think any text
would be enough to cover such cases, as they're punctual.

Probably the only thing that could be more effective would be to have
an e-signed CLA for the ones which become maintainers.


Thanks,
Mauro

  reply	other threads:[~2025-08-22 11:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-21  8:56 [MAINTAINER SUMMIT] Adding more formality around feature inclusion and ejection James Bottomley
2025-08-21 16:27 ` Steven Rostedt
2025-08-21 17:44   ` James Bottomley
2025-08-21 19:15     ` Steven Rostedt
2025-08-22  7:59       ` James Bottomley
2025-08-21 19:32   ` Paul Moore
2025-08-22 11:39   ` Mauro Carvalho Chehab
2025-08-22 13:15     ` Matthew Wilcox
2025-08-21 20:34 ` Theodore Ts'o
2025-08-21 20:59   ` Theodore Ts'o
2025-08-21 22:21   ` Matthew Wilcox
2025-08-22 11:29     ` Mauro Carvalho Chehab [this message]
2025-08-22  8:09   ` James Bottomley
2025-08-22 12:03     ` Greg KH
2025-08-22 12:08       ` Rafael J. Wysocki
2025-08-22 12:24       ` Theodore Tso
2025-08-22 15:31         ` James Bottomley
2025-08-22 16:09           ` Theodore Tso
2025-08-25  8:20           ` Mauro Carvalho Chehab
2025-08-25  7:57         ` Mauro Carvalho Chehab
2025-08-22 15:19       ` James Bottomley
2025-08-23  1:03 ` dan.j.williams

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=20250822132943.1ca76a8a@foz.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=ksummit@lists.linux.dev \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.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 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.