Re: [MAINTAINER SUMMIT] Adding more formality around feature inclusion and ejection

["Theodore Tso" <tytso@mit.edu>]

On Fri, Aug 22, 2025 at 02:03:13PM +0200, Greg KH wrote:
> 
> It's not our job to quell "internet speculation", sorry.  Just because
> we normally work in public for almost everything, doesn't mean that some
> things can't be done in private as well.  And again, just because you
> haven't seen a public decision doesn't mean that there hasn't been one
> made :)

The other thing I'll add here is that the best analogy I can think of
here is that this is a HR / Personnel issue.  These sorts of things,
whether they are a matter of someone not working well with the team
(at which point the manager needs to figure out how to resolve the
issue, and will often need to engage in private mediation /
interventions), or being caught on camera at a Coldplay concert, will
always have private conversations that will never be made part of the
public record --- as it should be, as much as content creators looking
for clickbait might wish otherwise.

Now, if what James is trying to say is that we could have avoided the
whole situation by refusing to allow bcachefs to be included in the
first place, I'm going to have to respectfully disagree with that
proposal as a way to avoid problems in the future.

I'm not sure that the fact that various developer-to-developer
relationships would have degraded to the point that it had by the end
of this whole saga could have been predicted at the point when we were
making the "to include or not to include bcachefs in Linux mainline".
I don't think we could have predicted whether or not a perspective
future maintainer would utterly refuse private offers of coaching from
the beginning.  And I don't think we should proactively refuse to
accept a feature just because someone's inter-personal relationships
are not perfect.

The current baseline is that the media subsystem, networking, or BPF
maintainer's decide what features to accept and who they will accept
pull requests from.  The same us true all the way up the hierarchy
maintainer tree up to Linus.  What is the alternative that we could
use?  That some democratic voting procedure, or some kind of core team
would stick their oar into making this decision?  I'm not sure that
would be an improvement; in fact, IMHO, it will very likely be
significantly worse.

I'm sure that as a result of this whole sitution, maintainers may very
well be more careful before accepting a new feature from a perspective
submaintainer who might be challenged in the teamwork department.  But
I'm not sure trying to codify this would be helpful --- because I
fundamentally disagree with the premise that we can accurately predict
how future stories will end.  Hindsight, after all, is 20/20.

If someone wants to suggest a concrete proposal, perhaps that's
something we can discuss.  But my personal opinion is having an
open-ended discussion of how we could have avoided the messiness of
bcachefs would probably not be a good use of time at the Maintainer's
Summit.

						- Ted