Sorry for the lack of progress on some of the b4 features -- I've been focusing on finishing up list migrations and planning some long-overdue infra upgrades to happen this year.

Unfortunately, my request to be able to dedicate more time to kernel developer tooling hasn't been approved yet. I need to put together a small report of what we were already able to get done with lore and b4 and what I hope to accomplish if I'm able to dedicate more time to working on it. Without that, there's a perception at LF that I'm just putting band-aids on a process that's beyond fixing and it's better to just move everyone over to GitHub/GitLab instead.

(Yes, I know that 50% of maintainers will vehemently agree with that statement, but I also know that 50% of others will just as vehemently disagree with it. My preferred course of action is iterative changes that would allow integrating forge workflows with the traditional decentralized model without having the whole thing rip apart. Now I just need to put this into words and plans.)

@monsieuricon
That 50% is a little skewed. It's the people who are already familiar and using this system.
Maybe if you migrate to a better process, the number of new contributers turn that 50% to a way higher ratio?! Maybe.

@monsieuricon I suggest we get the maintainers together in two teams and fight to the death to resolve the debate once and for all. In the mean time I’m thinking about the same problems for Yocto (handily, also on LF infra) so I’m following your account closely!

@ross both sides have valid and irreconcilable objections -- it's I-don't-want-your-single-point-of-failure-on-proprietary-stack people vs. email-is-terrible-and-lossy-let's-move-out-of-the-nineties-already people.

@monsieuricon aye, I’ve been in enough of these arguments to have started towards the opinion that at some point the maintainer just has to pick and everyone else deals with it.

@monsieuricon although surely a self-hosted open source forge thing mitigates some of the fears of the modern? There are several options.

@ross not the single-point-of-failure bit. :) I'm watching forgejo's ActivityPub federated features, plus still keeping an eye on radicle.xyz (less so after they chugged the entire pitcher of web3 koolaid at some point in recent history).

@monsieuricon I’d be dubious of anyone who chugged web3 too.

@monsieuricon LMK if you need any help, we've moved to b4/public-inbox/patchwork in a handful of places and it's been really great.

@gregkh I don't want to say it wouldn't work for anyone -- it clearly works well for some subsystems. It's just that it's a helluva lot more complicated than throwing together a quick hosted solution and then declaring a flag day of "from this day onward everyone uses this new thing." For every problem we'll solve this way, we'll gain 10 more, not to mention lose some of the more valuable maintainers who are already strained.

@gregkh I'll be happy to split a drink with you over it in S-D, though! :)

@monsieuricon it's truly bizarre to see LF argue in favor of moving to centralized forges after SFC's Give Up GitHub initiative last year, wow

@monsieuricon as an occasional kernel contributor, b4 has been by far the best tooling improvement in 2023 for me. Thanks for making it!

@gregkh @monsieuricon even as someone hard in favor of the email workflow I think that forges are compatible with the Linux model. Many subsystems are already maintained on a forge and batch up patches to submit upstream and if it works for them that's great. Totally compatible with the distributed model of Linux development, though I don't expect us to see torvalds or linux-staging on gitlab or whatever.

@drewdevault @gregkh @monsieuricon A friend of mine has been making this argument for a long time.

Many subsystems already operate this way and it works fine. git is distributed, after all.

I know this wasn't the point you were making - nor my friend, but one can obviously take the sourcehut model as well. Forge as a ~frontend to MLs can help a lot.