From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: ksummit@lists.linux.dev
Cc: linux-fsdevel@vger.kernel.org
Subject: [MAINTAINER SUMMIT] Adding more formality around feature inclusion and ejection
Date: Thu, 21 Aug 2025 09:56:15 +0100 [thread overview]
Message-ID: <fc0994de40776609928e8e438355a24a54f1ad10.camel@HansenPartnership.com> (raw)
I think the only point of agreement on this topic will be that how
bcachefs was handled wasn't correct at many levels. I think this shows
we need more formality around feature inclusion, including a possible
probationary period and even things like mentorship and we definitely
need a formal process that extends beyond Linus for deciding we can no
longer work with someone any more. I don't think anyone has the right
answer on this so (shock, horror), this is a genuine discussion topic
and one that would probably extend beyond the maintainer summit. The
problem is that while the bcachefs saga did stray into CoC territory,
the fundamental issues were technical and community not around conduct
and I think a large part of the solution will involve discussing how
you mentor someone in community building and how you objectively
measure when they're failing to the extend that they're damaging
surrounding communities.
We probably also all have somewhat of an evolution of our positions on
this as well so I can start the ball rolling by detailing mine. It's
public that I thought bcachefs shouldn't have gone in in the first
place:
https://lore.kernel.org/all/?q=f:bottomley%20s:bcachefs
for most of the problems it eventually caused. However after mature
reflection, I think this was wrong: ab initio exclusion, even with
valid and evidence based reasons, will make us into a narrow minded and
ossified club. I still think there should be discussion of the ab
initio problems but they should form part of the probation and
development plan for the feature, so everyone knows they always have a
chance to prove that they can do better than others thought at the
time. It is probable that this probation and development plan can be
evolved at the time over email (I don't think one size fits all is ever
going to work for this) but a key point will be having at least one and
possibly more existing maintainers being responsible for executing it
(finding these people is going to be a challenge, I know). The second
part is even more problematic: how do you measure forward progress
during the probationary period and judge whether the training wheels
should come off or the feature should be ejected? If there's a clear
plan, then assessing progress against that solves some of the problem,
but not all and if the final decision is no instead of yes, there needs
to be a written down set of reasons for why this is (and possibly a
post mortem discussion of how everyone could do better next time
around).
However, I'm sure others will have different ideas.
Regards,
James
next reply other threads:[~2025-08-21 8:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 8:56 James Bottomley [this message]
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
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=fc0994de40776609928e8e438355a24a54f1ad10.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=ksummit@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox