Message-ID: <20250207-mature-pastel-rottweiler-e6dbd9@lemur>
Date: Fri, 7 Feb 2025 12:14:36 -0500
From: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To: Hector Martin <marcan@...can.st>
Cc: Danilo Krummrich <dakr@...nel.org>, Dave Airlie <airlied@...il.com>, 
	Jason Gunthorpe <jgg@...dia.com>, Greg KH <gregkh@...uxfoundation.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, phasta@...nel.org, Christoph Hellwig <hch@....de>, 
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Abdiel Janulgue <abdiel.janulgue@...il.com>, 
	daniel.almeida@...labora.com, aliceryhl@...gle.com, robin.murphy@....com, 
	rust-for-linux@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>, 
	Valentin Obst <kernel@...entinobst.de>, open list <linux-kernel@...r.kernel.org>, 
	Marek Szyprowski <m.szyprowski@...sung.com>, airlied@...hat.com, 
	"open list:DMA MAPPING HELPERS" <iommu@...ts.linux.dev>, DRI Development <dri-devel@...ts.freedesktop.org>
Subject: Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma
 coherent allocator abstraction.)

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.

-K

Powered by blists - more mailing lists