* Hector Martin (marcan@xxxxxxxxx) wrote: > On 2025/02/08 2:14, Konstantin Ryabitsev wrote: > > On Fri, Feb 07, 2025 at 05:16:28AM +0900, Hector Martin wrote: > >> And what I see, is very little effort to improve that status quo, or at > >> least very little that yields any actual change that isn't just > >> band-aids (e.g. tooling like b4, which is nice and appreciated, but > >> doesn't fix any underlying issues). And that's not going to change no > >> matter how many long technical arguments we have on the MLs (or even off > >> MLs, since MLs are also not particularly good for this, and I've seen > >> multiple arguments only reach a resolution after being redirected to IRC). > > > > From my perspective, there are several camps clashing when it comes to the > > kernel development model. One is people who are (rightfully) pointing out that > > using the mailing lists was fine 20 years ago, but the world of software > > development has vastly moved on to forges. > > > > The other camp is people who (also rightfully) point out that kernel > > development has always been decentralized and we should resist all attempts to > > get ourselves into a position where Linux is dependent on any single > > Benevolent Entity (Github, Gitlab, LF, kernel.org, etc), because this would > > give that entity too much political or commercial control or, at the very > > least, introduce SPoFs. > > > > At best, I can hope to make both camps grumpily agree to coexist. > > > > I *am* very wary of Benevolent Entities, because we have too many very recent > > examples of companies "realigning priorities" when political winds shift. > > Programs and initiatives that have until recently been poster board examples > > of progress and benevolence are shuttered and defunded. I am concerned that > > we're only a couple of mood swings away from someone deciding that free > > software should not be allowed to exist because it benefits America's foes. > > Many of us remember all too well when large tech giants treated Linux as a > > "cancer" to be opposed, and I can certainly see that idea easily re-entering > > some Big Brain in Charge. > > > > From my perspective, I would like to ensure that Linux development can > > continue without a hard dependency on a single centralized forge -- whether > > controlled by a large commercial entity, or even a standalone one that is > > operated by kernel.org. It's becoming shockingly difficult to operate a public > > resource on the web unless you're willing to put it behind a large commercial > > CDN that will protect you from hostile bots (and if you do that, you're back > > to depending on the whims of a Benevolent Entity). > > > > We're trying to get lore.kernel.org to the point where it's like a global > > messaging bus that is indexed and searchable. Currently, you mostly have to > > send things to a mailing list for them to end up on lore, but it's gradually > > becoming less and less the case. We're already bridging with bugzilla and we > > should be able to bridge with forges soon, too (currently delayed again > > because I'm scrambling to move kernel.org frontends away from Equinix). Who > > knows, we may be actually leapfrogging the forge era of software development > > straight into "AI" agents era -- but that remains to be seen. > > > > Anyway, all of this is to say that I'm happy that you've found b4 useful, but > > I wouldn't view it as a band-aid -- it's just a very small and email-centric > > way to interact with the kernel lore. > > > > The centralization concern is valid, but there are technical solutions > to this, such as forge federation. It's possible to set up a forge > environment to be less of a SPoF, such as by ensuring all data is open > and archiveable to allow for migration and backup restore, even by third > parties (you can make practically ~all forge data public except for > login passwords, and we have email-based reset processes for those). > It's also possible to simply shard, and let different subsystems choose > their own forge infrastructure, so downtime has a more limited effect. > > Meanwhile, for better or worse, much of Linux infra *is* centralized - > for example, the mailing lists themselves, and a lot of the Git hosting. Although, many of the subsystems have their own patchworks or other systems anyway dotted in random places. It's actually something I find quite hard, it might seem there is *a* Linux contribution process, but if you do fixups or devices all over rather than in one subsystem you end up tripping over the oddities of each maintainer; then trying to figure out when they're prepared to take a patch, or where to check for whether they've taken it, or whether to expect it to turn up in -next can all be quite random. <snip> > - Hector Dave > > -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
