Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.)

[Neal Gompa <neal@gompa.dev>]

On Friday, February 7, 2025 1:16:11 PM Eastern Standard Time Konstantin 
Ryabitsev wrote:
> On Sat, Feb 08, 2025 at 03:02:11AM +0900, Hector Martin wrote:
> > The centralization concern is valid, but there are technical solutions
> > to this, such as forge federation.
> 
> Unfortunately, forge federation is really only between Forgejo instances and
> is still pretty nascent, afaict. The most promising development in
> decentralized forges that I've seen is Radicle, but I'm yet to try it again
> ever since they got collectively drunk on bitcoin coolaid a few years ago.

Strictly speaking, this isn't true. Forgefed federation was tested very early 
on with Codeberg's Gitea fork (before it was called Forgejo) and Pagure with 
its Forgefed extension[1]. The initial design and development was across three 
forge systems (Vervis, Forgejo, and Pagure).

Even before that, Pagure has data portability built into its design in a way 
no other forge has today: all project metadata is stored as JSON data checked 
into specialized Git repos. That means it's trivial to mirror and archive 
projects to have redundant instances or failover instances to support whatever 
reliability and high availability guarantees you'd like.

And insofar as cross system contributions, Pagure supports making pull 
requests that pull from arbitrary Git servers (as long as the Pagure instance 
can connect to it) with its remote pull request feature. That has been a core 
feature for nearly the entire time it has existed.

It's not that it wasn't possible, it's just nobody cares. In the 11 years 
since Pagure was created, literally no other forge has even intimated that 
they want even *some* of the concepts Pagure has. Extensibility and 
portability are simply not important concepts to anyone anymore.

If it was, maybe more people would have been excited about Pagure, I'd have 
more contributors to that project, and there'd be more deployments out there 
showing it off.

It is what it is, I guess. ☹️

[1]: https://pagure.io/pagure-forgefed

> > Meanwhile, for better or worse, much of Linux infra *is* centralized -
> > for example, the mailing lists themselves, and a lot of the Git hosting.
> 
> Yes, but it's at least resilient. If someone knocks out vger.kernel.org,
> kernel development will still continue because maintainers are still cc'd
> directly via email, and email is still the only widely adopted federated
> platform that we have, with nothing else coming anywhere close.
> 

That's really a self-inflicted choice. Adoption is always a catch-22. If you 
really wanted federated forge development and have some aspect of 
decentralized development, you always can even with forges or other tools. 
It's just not something being considered or explored in the Linux kernel 
community, despite how much some folks dislike the email-based workflow.

> > At the end of the day, I do not believe a theoretical breakdown of Linux
> > infra would be a major long-term setback to Linux kernel development.
> 
> We know it's the case when kernel.org went off the air for months in 2011.
> :) Let's keep it that way!
> 
> > But I'm afraid you'll find much if not most of the true opposition to
> > forges is not technical, it is philosophical or preference-based (even
> > though it may be presented as technical opposition, sometimes to
> > intentionally mislead). This is, in fact, quite a mirror of the R4L
> > situation, where technical arguments ("show me you can write a real
> > driver") quickly lead to non-technical arguments when solutions are
> > proposed ("it's cancer").
> > 
> > I actually considered moving soc/apple development to a forge personally
> > in the near future (obviously not my call to make any more), and I was
> > fully expecting a pile of pushback, "because that's not how we do things
> > here". Who knows, I might have gotten a "fuck you, either you accept
> > email patches or I remove you from MAINTAINTERS" from Linus.
> 
> It is my goal to be able to give subsystems a way to use forges without it
> impacting how they interact with upstream or handle tree-wide changes. That
> is, once I'm done moving things from one Benevolent Company to another.
> 

Honestly, this is probably not possible. If a subsystem moves to a forge 
workflow, it pretty much means tree-wide changes need to work partially that 
way too.


-- 
真実はいつも一つ！/ Always, there's only one truth!