On Fri, 2025-08-22 at 08:24 -0400, Theodore Tso wrote: > 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 did tackle that in the original proposal: https://lore.kernel.org/all/fc0994de40776609928e8e438355a24a54f1ad10.camel@xxxxxxxxxxxxxxxxxxxxx/ But for those who didn't read it the precis is I said on reflection I wouldn't ban anything at the inclusion stage even though that's what I initially argued for > 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. I think one takeaway is that there were a bunch of predictions which ultimately turned out to be true and to make a success of it we should have had a plan for coping with the foreseen issues. > 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. When did this become about how our current maintainer pull system works? I'm certainly not advocating changing it. > 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. I don't think anyone made that premise. However, when problems are foreseen its not unreasonable to plan to try to overcome them and be successful. > 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. Well I did ask for two concrete things, but I can certainly repeat: On Fri, 2025-08-22 at 09:09 +0100, James Bottomley wrote: > I think I'd be happy if we sort out two things > > 1. That the decision be taken by more than one person rather than > abdicating to last man standing > 2. The outcome be documented clearly. > Regards, James
