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
