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

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

[Simona Vetter]

On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
> Adding Linus
> 
> My 2c: If Linus doesn't pipe up with an authoritative answer to this
> thread, Miguel and the other Rust folks should just merge this series
> once it is reviewed and ready, ignoring Christoph's overt attempt at
> sabotaging the project. If Linus pulls it, what Christoph says doesn't
> matter. If Linus doesn't pull it, the R4L project is essentially dead
> until either Linus or Christoph make a move. Everything else is beating
> around the bush.
> 
> Rust folks: Please don't waste your time and mental cycles on drama like
> this. It's not worth your time. Either Linus likes it, or he doesn't.
> Everything else is distractions orchestrated by a subset of saboteur
> maintainers who are trying to demoralize you until you give up, because
> they know they're going to be on the losing side of history sooner or
> later. No amount of sabotage from old entrenched maintainers is going to
> stop the world from moving forward towards memory-safe languages.
> 
> FWIW, in my opinion, the "cancer" comment from Christoph would be enough
> to qualify for Code-of-Conduct action, but I doubt anything of the sort
> will happen.

Yeah no.

https://chaos.social/@sima/113942119012147959

This was about you, because typing a proper answer takes a bit longer. It
was also about your toots on fedi, like this:

https://social.treehouse.systems/@marcan/113941468353031993

And "haha it's only a joke" does not work with your public profile and following.

I do understand the frustration and temptation to just burn it all to the
ground, head the call of the sirens, or maybe for me more pick up goat
farming in the Swiss Alps. But you can't have it both and expect to also
be part of and contribute to the same community. And personally I don't
appreciate getting drenched in gasoline while I'm trying to quench flames
on the ground.

And this isn't the first time or the second, by now it's a pretty clear
pattern over some years. And with the first I could explain why you react
like that and you had my full understanding, but eventually that runs a
bit thin as an excuse.  Now I'm left with the unlikely explanation that
you just like thundering in as the cavalry, fashionably late, maximally
destructive, because it entertains the masses on fedi or reddit or
wherever. I have no idea what you're trying to achieve here, I really
don't get it, but I am for sure fed up dealing with the fallout.

Cheers, Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[Dave Airlie]

On Thu, 6 Feb 2025 at 04:52, Simona Vetter <simona.vetter@ffwll.ch> wrote:
>
> On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
> > Adding Linus
> >
> > My 2c: If Linus doesn't pipe up with an authoritative answer to this
> > thread, Miguel and the other Rust folks should just merge this series
> > once it is reviewed and ready, ignoring Christoph's overt attempt at
> > sabotaging the project. If Linus pulls it, what Christoph says doesn't
> > matter. If Linus doesn't pull it, the R4L project is essentially dead
> > until either Linus or Christoph make a move. Everything else is beating
> > around the bush.
> >
> > Rust folks: Please don't waste your time and mental cycles on drama like
> > this. It's not worth your time. Either Linus likes it, or he doesn't.
> > Everything else is distractions orchestrated by a subset of saboteur
> > maintainers who are trying to demoralize you until you give up, because
> > they know they're going to be on the losing side of history sooner or
> > later. No amount of sabotage from old entrenched maintainers is going to
> > stop the world from moving forward towards memory-safe languages.
> >
> > FWIW, in my opinion, the "cancer" comment from Christoph would be enough
> > to qualify for Code-of-Conduct action, but I doubt anything of the sort
> > will happen.
>
> Yeah no.
>
> https://chaos.social/@sima/113942119012147959
>
> This was about you, because typing a proper answer takes a bit longer. It
> was also about your toots on fedi, like this:
>
> https://social.treehouse.systems/@marcan/113941468353031993
>
> And "haha it's only a joke" does not work with your public profile and following.
>
> I do understand the frustration and temptation to just burn it all to the
> ground, head the call of the sirens, or maybe for me more pick up goat
> farming in the Swiss Alps. But you can't have it both and expect to also
> be part of and contribute to the same community. And personally I don't
> appreciate getting drenched in gasoline while I'm trying to quench flames
> on the ground.
>
> And this isn't the first time or the second, by now it's a pretty clear
> pattern over some years. And with the first I could explain why you react
> like that and you had my full understanding, but eventually that runs a
> bit thin as an excuse.  Now I'm left with the unlikely explanation that
> you just like thundering in as the cavalry, fashionably late, maximally
> destructive, because it entertains the masses on fedi or reddit or
> wherever. I have no idea what you're trying to achieve here, I really
> don't get it, but I am for sure fed up dealing with the fallout.
>

To back up Sima here, we don't need grandstanding, brigading, playing
to the crowd, streamer drama creation or any of that in discussions
around this.

The r4l team and drm maintainer team have this sort of thing in hand,
it's not like we don't understand the community of the Linux kernel,
and having this first reaction to blow shit up and dramatise it just
isn't helpful.

Being toxic on the right side of an argument is still toxic, please
try and be better, and maybe take a step back and consider is what you
are posting going to help the discussion or just adding pointless
drama to it.

Dave.

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

[Hector Martin]

On 2025/02/06 5:36, Dave Airlie wrote:
> On Thu, 6 Feb 2025 at 04:52, Simona Vetter <simona.vetter@ffwll.ch> wrote:
>>
>> On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
>>> Adding Linus
>>>
>>> My 2c: If Linus doesn't pipe up with an authoritative answer to this
>>> thread, Miguel and the other Rust folks should just merge this series
>>> once it is reviewed and ready, ignoring Christoph's overt attempt at
>>> sabotaging the project. If Linus pulls it, what Christoph says doesn't
>>> matter. If Linus doesn't pull it, the R4L project is essentially dead
>>> until either Linus or Christoph make a move. Everything else is beating
>>> around the bush.
>>>
>>> Rust folks: Please don't waste your time and mental cycles on drama like
>>> this. It's not worth your time. Either Linus likes it, or he doesn't.
>>> Everything else is distractions orchestrated by a subset of saboteur
>>> maintainers who are trying to demoralize you until you give up, because
>>> they know they're going to be on the losing side of history sooner or
>>> later. No amount of sabotage from old entrenched maintainers is going to
>>> stop the world from moving forward towards memory-safe languages.
>>>
>>> FWIW, in my opinion, the "cancer" comment from Christoph would be enough
>>> to qualify for Code-of-Conduct action, but I doubt anything of the sort
>>> will happen.
>>
>> Yeah no.
>>
>> https://chaos.social/@sima/113942119012147959
>>
>> This was about you, because typing a proper answer takes a bit longer. It
>> was also about your toots on fedi, like this:
>>
>> https://social.treehouse.systems/@marcan/113941468353031993
>>
>> And "haha it's only a joke" does not work with your public profile and following.
>>
>> I do understand the frustration and temptation to just burn it all to the
>> ground, head the call of the sirens, or maybe for me more pick up goat
>> farming in the Swiss Alps. But you can't have it both and expect to also
>> be part of and contribute to the same community. And personally I don't
>> appreciate getting drenched in gasoline while I'm trying to quench flames
>> on the ground.
>>
>> And this isn't the first time or the second, by now it's a pretty clear
>> pattern over some years. And with the first I could explain why you react
>> like that and you had my full understanding, but eventually that runs a
>> bit thin as an excuse.  Now I'm left with the unlikely explanation that
>> you just like thundering in as the cavalry, fashionably late, maximally
>> destructive, because it entertains the masses on fedi or reddit or
>> wherever. I have no idea what you're trying to achieve here, I really
>> don't get it, but I am for sure fed up dealing with the fallout.
>>
> 
> To back up Sima here, we don't need grandstanding, brigading, playing
> to the crowd, streamer drama creation or any of that in discussions
> around this.
> 
> The r4l team and drm maintainer team have this sort of thing in hand,
> it's not like we don't understand the community of the Linux kernel,
> and having this first reaction to blow shit up and dramatise it just
> isn't helpful.
> 
> Being toxic on the right side of an argument is still toxic, please
> try and be better, and maybe take a step back and consider is what you
> are posting going to help the discussion or just adding pointless
> drama to it.
> 
> Dave.

I'm tired.

I'm tired of seeing positive, technically impressive kernel projects
blockaded delayed by maintainers with no technical justification, and at
best end up moving along at a glacial pace.

I'm tired of seeing important contributors and maintainers give up and
throw the towel after enduring repeated misbehavior and hostility
towards their efforts from others.

I'm tired of getting messages, privately and publicly, from all kinds of
people, saying they won't touch the kernel with a 10-foot pole due to
the hostility and the baroque, regressive process.

I'm tired of seeing people get away with using words like "cancer" to
describe others' work, with zero repercussion.

I'm tired of *politely and calmly* calling out hostile and unwelcoming
behavior from maintainers and suggest ways to improve, only to be
ignored and nothing change (note: this refers to other instances, not
this instance).

I'm tired of having to spend hours or days of my time to upstream simple
things, because even the simplest of changes en up in a bikeshed.

I'm tired of having to manually format code instead of using clang-format.

I'm tired of drive-by nitpickers who send useless review comments on
code they don't take the time to understand.

I'm tired of having to review patches in an email client, where I can't
even tell which patches are for me to merge and not without writing
complex filtering rules to correlate email bodies with kernel subsystem
paths, which I don't have the time to write and maintain.

I'm tired of having to type a half dozen `b4` commands just to send a
change.

And I'm tired of hearing things will get better if I just "trust the
process" or let people work from within, while nothing seems to have
actually changed in years despite endless discussion about these
problems on the sidelines.

If shaming on social media does not work, then tell me what does,
because I'm out of ideas.

- Hector

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

[Linus Torvalds]

On Thu, 6 Feb 2025 at 01:19, Hector Martin <marcan@marcan.st> wrote:
>
> If shaming on social media does not work, then tell me what does,
> because I'm out of ideas.

How about you accept the fact that maybe the problem is you.

You think you know better. But the current process works.

It has problems, but problems are a fact of life.  There is no perfect.

However, I will say that the social media brigading just makes me not
want to have anything at all to do with your approach.

Because if we have issues in the kernel development model, then social
media sure as hell isn't the solution. The same way it sure as hell
wasn't the solution to politics.

Technical patches and discussions matter. Social media brigading - no
than\k you.

                 Linus

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

[Dr. Greg]

On Thu, Feb 06, 2025 at 09:58:36AM -0800, Linus Torvalds wrote:

Good morning to everyone.

> On Thu, 6 Feb 2025 at 01:19, Hector Martin <marcan@marcan.st> wrote:
> >
> > If shaming on social media does not work, then tell me what does,
> > because I'm out of ideas.

> Because if we have issues in the kernel development model, then
> social media sure as hell isn't the solution. The same way it sure
> as hell wasn't the solution to politics.
>
> Technical patches and discussions matter. Social media brigading - no
> thank you.

I truely wish that technical patches and discussions were the currency
that matter but I believe we are struggling with that, at least in
some venues in the kernel development process.

No one should construe that statement as an endorsement of berating
people on social media as the 'fix'.

I come at this from the perspective of having worked on Linux since
around December of 1991.  I first met you and Tove in 1995 at the Free
Software Conference at MIT that Stallman sponsored.  When we first
met, I told you that cancer patients in North Dakota were enjoying
more time with their families because of what we were able to do with
Linux and optimizing medical processes at our Cancer Center.

RedHat paid me to speak at a number of conferences in the 90's talking
about how Linux was going to dominate enterprise computing, given that
it was about technology people doing the 'right' technology thing.

I'm seeing things that make me regret those words.

Probably the last technical contribution of my career is leading an
initiative to provide the Linux community a generic security modeling
architecture.  Not to supplant or replace anything currently being
done, but to provide a flexible alternative to the development of
alternate and/or customized workload models, particularly in this era
of machine learning and modeling.

Four patch series over two years, as of yesterday, not a single line
of code ever reviewed.

For a contribution that touches nothing outside of its own directory
and does nothing unless people choose to execute a workload under its
control.

We were meticulous in our submissions to avoid wasting maintainers
time.  We even waited two months without hearing a word before we sent
an inquiry as to the status of one of the submissions.  We were told,
rather curtly, that anything we sent would likely be ignored if we
ever inquired about them.

We tried to engage, perhaps to excess, in technical discussions
attempting to explain why and how we chose to implement what we were
proposing.  Including input from advisors who are running production
IT systems that feel that there needs to be better approaches to
addressing their security needs.

There were never any relevant technical exchanges.  The discussion
consisted of, we have decided to do things a certain way, no
discussion, if you don't like that you should really consider doing
something other than submitting to upstream Linux.

The all powerful sub-system maintainer model works well if the big
technology companies can employ omniscient individuals in these roles,
but those types are a bit hard to come by.  Lacking that, there is the
tangible risk of stifling innovation and Linux is the only place that
innovation can occur in the operating system space.

Not sure what the fix is, from a project management perspective the
technology industry has never faced a challenge like this.  The fork
model, which was the classic protection in open-source, doesn't work
at this scale.

We have a Code Of Conduct that we can't scream or hurl four letter
words and insults at one another.  Maybe it already exists but a Code
Of Standards for maintainers would seem to be an imperative if we are
going to move forward productively.  Jim are you listening?

Obviously respect and open-mindedness to new ideas appears to be the
grease that makes all of this run smoothly.  Unfortunately that seems
to be about as rare a commodity as omniscience in our industry.

>                  Linus

Linus, best wishes to you and your family, it has been a fascinating
ride and thing to watch.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

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

[Steven Rostedt]

On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
> 
> Not sure what the fix is, from a project management perspective the
> technology industry has never faced a challenge like this.  The fork
> model, which was the classic protection in open-source, doesn't work
> at this scale.

Maybe not quite a fork, but I wonder if the Rust project did something similar
to what PREEMPT_RT did. That was to keep an out of tree patch. The full patch
was just merged last September after being out of tree for a good 20 years.

In the beginning there was a few things in that patch that Christoph was
against, but over time he became accepting of it.

Yes, being out of tree is very difficult because you have to constantly rebase
(we actually found quilt being a better tool than git in this case!). But it
also gives you full flexibility to try new approaches. Just because something
is out of tree doesn't mean it can't be published and used. Red Hat and SUSE,
as well as many others shipped PREEMPT_RT while it was out of tree.

Note, even though PREEMPT_RT started in 2004 and wasn't fully merged until
2024, it slowly did creep in bit by bit. For example, here's a few things that
came from the RT patch, and each was rewritten at least 3 times to become
acceptable by the upstream maintainers:

  - NOHZ
  - High res timers
  - threaded interrupts
  - mutex code (yes, before RT everything used a semaphore)
  - lockdep
  - ftrace
  - generic interrupt code
  - generic timer code
  - priority inheritance
  - SCHED_DEADLINE
  - RT push/pull scheduling

and more.

Point being, if you are having issues with getting code upstream, don't be
afraid to make it out of tree. Just make it easy for others to use. And slowly
move your code into mainline. This is also a way to prove beyond a doubt how
useful your code is. The number of users is a technical argument. Linus does
pull things in when there is a large user base, even over other maintainer's
objections (see sched_ext).

It worked for us, it can work for you ;-)

-- Steve

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

[Steven Rostedt]

On Fri, Feb 07, 2025 at 11:26:50PM -0500, Steven Rostedt wrote:
> 
> Note, even though PREEMPT_RT started in 2004 and wasn't fully merged until
> 2024, it slowly did creep in bit by bit. For example, here's a few things that
> came from the RT patch, and each was rewritten at least 3 times to become
> acceptable by the upstream maintainers:
> 
>   - NOHZ
>   - High res timers
>   - threaded interrupts
>   - mutex code (yes, before RT everything used a semaphore)
>   - lockdep
>   - ftrace
>   - generic interrupt code
>   - generic timer code
>   - priority inheritance
>   - SCHED_DEADLINE
>   - RT push/pull scheduling
> 
> and more.
> 

Here's a little bit of Linux trivia. KVM was first introduced to Linux via the
RT patch. Because it was such a new technology and they didn't want to break
the Linux workflow, we agreed to take their changes so that they could try out
different methods and have users without being committed to something and have
their changes break upstream Linux.

Sound familiar?

-- Steve

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

[Hector Martin]

On 2025/02/08 13:26, Steven Rostedt wrote:
> On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
>>
>> Not sure what the fix is, from a project management perspective the
>> technology industry has never faced a challenge like this.  The fork
>> model, which was the classic protection in open-source, doesn't work
>> at this scale.
> 
> Maybe not quite a fork, but I wonder if the Rust project did something similar
> to what PREEMPT_RT did. That was to keep an out of tree patch. The full patch
> was just merged last September after being out of tree for a good 20 years.
> 
> In the beginning there was a few things in that patch that Christoph was
> against, but over time he became accepting of it.
> 
> Yes, being out of tree is very difficult because you have to constantly rebase
> (we actually found quilt being a better tool than git in this case!). But it
> also gives you full flexibility to try new approaches. Just because something
> is out of tree doesn't mean it can't be published and used. Red Hat and SUSE,
> as well as many others shipped PREEMPT_RT while it was out of tree.

By kernel and mesa policy, while a drm/ kernel driver is not merged with
a stable UAPI, the mesa side cannot be merged/enabled either. That means
that every day the driver isn't upstream, our users suffer due to
various container technologies not shipping the driver in userspace
since they ship upstream mesa.

The process is *designed* to encourage upstreaming early and *punish*
downstream trees.

It's not just distros shipping, or even typical container technologies
like Flatpak (we have a workaround for that specific one). We'd need to
get stuff like Android/AOSP to ship the patched userspace driver so it
works in Waydroid, which some people want to use. It is an impossible task.

Never mind that distros aren't, in fact, inclined to ship out-of-tree
kernels. PREEMPT_RT was an exception due to its general usefulness, and
even then was not available everywhere, and had a reasonable excuse for
being out-of-tree so long due to its intrusiveness in core code. Rust
and the Rust drivers aren't even remotely as intrusive, they just stay
off to the side in their own directories. Nobody wants to ship
downstream kernels just for random hardware support.

Out of tree doesn't work. People, both in the kernel and out of the
kernel, want things in tree.

- Hector

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

[Icenowy Zheng]

在 2025-02-08星期六的 17:31 +0900，Hector Martin写道：
> 
> By kernel and mesa policy, while a drm/ kernel driver is not merged
> with
> a stable UAPI, the mesa side cannot be merged/enabled either. That
> means
> that every day the driver isn't upstream, our users suffer due to
> various container technologies not shipping the driver in userspace
> since they ship upstream mesa.
> 
> The process is *designed* to encourage upstreaming early and *punish*
> downstream trees.

Well, at least some Mesa drivers are developed against some "vendor"
(even not community downstream) kernel drivers, e.g. powervr one;
although in the Asahi case there's no such vendor thing (because the HW
vendor is Darwin-only). In addition, I think at least some early
etnaviv development is based on drm/etnaviv drivers w/ in-kernel
version code earlier than the first in-kernel-tree version code (Well
drm version code rarely changes, but I think in the case of etnaviv it
really represents the UAPI).

Furtherly, the monorepo nature of Linux kernel means to refactor an
interface, it's usually the person changing the callee that need to
change all callers to satify the interface change; having Rust code in
tree calling the interface effectively means adding the responsibility
of fixing the Rust code when the interface changes, which could be not
acceptable by the C-only maintainers. In regards of adding a
maintainer, having more maintainers means more communication. The
situation of the current problem really shows how difficult
communication is, right?

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

[Danilo Krummrich]

On Mon, Feb 10, 2025 at 05:41:30PM +0800, Icenowy Zheng wrote:
> Furtherly, the monorepo nature of Linux kernel means to refactor an
> interface, it's usually the person changing the callee that need to
> change all callers to satify the interface change; having Rust code in
> tree calling the interface effectively means adding the responsibility
> of fixing the Rust code when the interface changes, which could be not
> acceptable by the C-only maintainers. In regards of adding a
> maintainer, having more maintainers means more communication.

This is exactly the same as for every new driver / component, regardless of
whether it is written in C or in Rust.

It is absolutely common that driver maintainers help with integrating core API
changes, if necessary.

I don't see why the same process should not work for Rust abstractions.

(Additionally, in this particular case even one of the reviewers of
DMA MAPPING HELPERS offered to be a reviewer of the Rust abstractions too, in
order to keep eye on the DMA API angle.)

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

[Icenowy Zheng]

在 2025-02-10星期一的 11:24 +0100，Danilo Krummrich写道：
> On Mon, Feb 10, 2025 at 05:41:30PM +0800, Icenowy Zheng wrote:
> > Furtherly, the monorepo nature of Linux kernel means to refactor an
> > interface, it's usually the person changing the callee that need to
> > change all callers to satify the interface change; having Rust code
> > in
> > tree calling the interface effectively means adding the
> > responsibility
> > of fixing the Rust code when the interface changes, which could be
> > not
> > acceptable by the C-only maintainers. In regards of adding a
> > maintainer, having more maintainers means more communication.
> 
> This is exactly the same as for every new driver / component,
> regardless of
> whether it is written in C or in Rust.
> 
> It is absolutely common that driver maintainers help with integrating
> core API
> changes, if necessary.
> 
> I don't see why the same process should not work for Rust
> abstractions.

Because integrating API changes could involve change to contexts of API
calls, which could be difficult for Rust situation, especially when
it's not required for core API maintainers to be able to write Rust.

> 
> (Additionally, in this particular case even one of the reviewers of
> DMA MAPPING HELPERS offered to be a reviewer of the Rust abstractions
> too, in
> order to keep eye on the DMA API angle.)

Sorry, but I did a fact check on this, and I found that the only
"reviewer" of DMA MAPPING HELPERS is Robin Murphy, he has only one
reply in this thread, and the reply only says "Indeed, FWIW it seems
like the appropriate level of abstraction to me, 
judging by the other wrappers living in rust/kernel/ already", he
didn't offer to be a reviewer, and he still says "Rust folks are happy
to take responsibility for un-breaking the 
Rust build if and when it happens".

He is just saying he's going to accept the abstraction, which should be
not able to forcibly override Christoph's explicit NACK here.

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

[Abdiel Janulgue]

Hi,

On 13/02/2025 05:49, Icenowy Zheng wrote:
> 
> Sorry, but I did a fact check on this, and I found that the only
> "reviewer" of DMA MAPPING HELPERS is Robin Murphy, he has only one
> reply in this thread, and the reply only says "Indeed, FWIW it seems
> like the appropriate level of abstraction to me,
> judging by the other wrappers living in rust/kernel/ already", he
> didn't offer to be a reviewer, 

Robin did offer:

https://lore.kernel.org/rust-for-linux/4956d01e-2d06-4edd-813b-9da94b482069@arm.com/

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

[Icenowy Zheng]

在 2025-02-13星期四的 08:41 +0200，Abdiel Janulgue写道：
> Hi,
> 
> On 13/02/2025 05:49, Icenowy Zheng wrote:
> > 
> > Sorry, but I did a fact check on this, and I found that the only
> > "reviewer" of DMA MAPPING HELPERS is Robin Murphy, he has only one
> > reply in this thread, and the reply only says "Indeed, FWIW it
> > seems
> > like the appropriate level of abstraction to me,
> > judging by the other wrappers living in rust/kernel/ already", he
> > didn't offer to be a reviewer, 
> 
> Robin did offer:
> 
> https://lore.kernel.org/rust-for-linux/4956d01e-2d06-4edd-813b-9da94b482069@arm.com/

Well okay it's a further thing.

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

[Danilo Krummrich]

On Thu, Feb 13, 2025 at 11:49:20AM +0800, Icenowy Zheng wrote:
> 在 2025-02-10星期一的 11:24 +0100，Danilo Krummrich写道：
> > 
> > (Additionally, in this particular case even one of the reviewers of
> > DMA MAPPING HELPERS offered to be a reviewer of the Rust abstractions
> > too, in
> > order to keep eye on the DMA API angle.)
> 
> Sorry, but I did a fact check on this, and I found that the only
> "reviewer" of DMA MAPPING HELPERS is Robin Murphy, he has only one
> reply in this thread, and the reply only says "Indeed, FWIW it seems
> like the appropriate level of abstraction to me, 
> judging by the other wrappers living in rust/kernel/ already", he
> didn't offer to be a reviewer,

As Abdiel pointed out already, he did offer it in [1].

But that's not the relevant part, but I think how you handled being in doubt is
relevant.

I think the correct way would have been to just ask for a pointer that proves
the statement in question.

Instead you just went ahead with the big words "fact check" and then even got it
wrong. In your "fact check" you did not put any disclaimer to e.g. indicate that
you might not have the full picture, etc.

Ultimately, the way you replied to this, comes across as an immediate accuse of
lying.

I really think that we should *not* pick up this way of arguing that nowadays
became all too present.

- Danilo

[1] https://lore.kernel.org/rust-for-linux/4956d01e-2d06-4edd-813b-9da94b482069@arm.com/

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

[Icenowy Zheng]

于 2025年2月13日 GMT+08:00 19:34:16，Danilo Krummrich <dakr@kernel.org> 写道：
>On Thu, Feb 13, 2025 at 11:49:20AM +0800, Icenowy Zheng wrote:
>> 在 2025-02-10星期一的 11:24 +0100，Danilo Krummrich写道：
>> > 
>> > (Additionally, in this particular case even one of the reviewers of
>> > DMA MAPPING HELPERS offered to be a reviewer of the Rust abstractions
>> > too, in
>> > order to keep eye on the DMA API angle.)
>> 
>> Sorry, but I did a fact check on this, and I found that the only
>> "reviewer" of DMA MAPPING HELPERS is Robin Murphy, he has only one
>> reply in this thread, and the reply only says "Indeed, FWIW it seems
>> like the appropriate level of abstraction to me, 
>> judging by the other wrappers living in rust/kernel/ already", he
>> didn't offer to be a reviewer,
>
>As Abdiel pointed out already, he did offer it in [1].
>
>But that's not the relevant part, but I think how you handled being in doubt is
>relevant.
>
>I think the correct way would have been to just ask for a pointer that proves
>the statement in question.
>
>Instead you just went ahead with the big words "fact check" and then even got it
>wrong. In your "fact check" you did not put any disclaimer to e.g. indicate that
>you might not have the full picture, etc

Well I'm sorry for using a too heavy word. I am not native English speaker
and not ablr to understand its suitability well.

>Ultimately, the way you replied to this, comes across as an immediate accuse of
>lying.
>
>I really think that we should *not* pick up this way of arguing that nowadays
>became all too present.
>
>- Danilo
>
>[1] https://lore.kernel.org/rust-for-linux/4956d01e-2d06-4edd-813b-9da94b482069@arm.com/

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

[Theodore Ts'o]

On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
> 
> The all powerful sub-system maintainer model works well if the big
> technology companies can employ omniscient individuals in these roles,
> but those types are a bit hard to come by.

I'll let you in a secret.  The maintainers are not "all-powerfui".  We
are the "thin blue line" that is trying to keep the code to be
maintainable and high quality.  Like most leaders of volunteer
organization, whether it is the Internet Engineerint Task Force (the
standards body for the Internet), we actually have very little power.
We can not *command* people to work on retiring technical debt, or to
improve testing infrastructure, or work on some particular feature
that we'd very like for our users.

All we can do is stop things from being accepted (either in our
subsystem, or the imprimatur of the IETF).  Hopefully, we're only
stopping bad things from progressing, but that *really* is all we can
actually do.

One of the things which gets very frustrating from the maintainer's
perspective is development teams that are only interested in their pet
feature, and we *know*, through very bitter experience, that 95+% of
the time, once the code is accepted, the engineers which contribute
the code will disappear, never to be seen again.  As a result, a very
common dynamic is that maintainers will exercise the one and only
power which they have --- which is to refuse to accept code until it
is pretty much perfect --- since once we accept the code, we instantly
lose all leverge, and the contributors will be disappear, and we will
be left with the responsibility of cleanig up the mess.  (And once
there are users, we can't even rip out the code, since that would be a
user-visible regression.)

Occasionally, there is an accusation that different standards that
might apply for people who are in the "gold old buys club".  But what
isn't appreciated, is that it is precisely because people who are
long-term members of the community are trusted to stick around and
will support code that the have sponsored.  For example, Darrick Wong,
who contributed ext4 metadata checksuming support before we moved on
to become the XFS maintainer, is still reviewing and making
contributions to code that he contributed many years to ext4.  I've
been known to submit fixes to test bugs for xfs-specific tests in
xfstests that I discovered when running daily spinner tests on the
linux git tree.

Just in the past two weeks, I've spent 15+ hours working on cleaning
up a casefold "security fix" that had nasty on-disk backwards
compatibility issues.  Part of it was that it was ext4 (although I
discovered that there was also fsck.f2fs problems that had been
overlooked), but the *other* part of why I spent so much time was that
I sponsored the casefolding patches, and so I felt I certain moral
responsibility to make sure the code was continued to be maintained.

(And note, this has nothing to do with who employs me; the 15-20 hours
that I spent working on creating the fix and the test scripts was
purely on my own time, on the weekend, or late at night.  The time
that I spend doing this isn't reflected in my performance reviews, or
promotion propects --- in fact, arguably, over the past 15 years, this
has probably slowed down my promotion prospects; I've only been
promoted once since joining said big tech company...)

> Not sure what the fix is, from a project management perspective the
> technology industry has never faced a challenge like this.  The fork
> model, which was the classic protection in open-source, doesn't work
> at this scale.

Well, here's my suggestion.  Teams that want to get features,
especially ones that might be potentially disruptive, into the tree,
need to spend time becoming part of the *community*.  This means that
they need to participate in part of the joint effort to keep the code
maintainable and high quaity --- even if it isn't part of their
company's short-term goals, or directly related to their pet feature
that they are trying to get upstream.

This was the trust of my "Beyond Upstream First" presentation which I
gave to the Linux Foundation Member Summit last fall[1].

[1] https://docs.google.com/presentation/d/11rMc8PBeyMItV6hv31OHSZ626_6FCZxjX6ZxEAehCpQ/edit#slide=id.p

Now, I'll say that the Rust developers are making strides in the right
direction here.  Miguel has stood for election for the Technical
Adviory Board, and has been contributing in various ways beyond just
Rust for Linux.  Ultimately, Cristoph's concern is that Rust is going
to make life harder for maintainers because of particular build breaks
getting in the way of the very limited bandwidth that Maintainers have
(and again, a lot of the work that we do gets done on our own personal
time; it's rare that even those maintainers employed by a "big
technology company" have complete freedom to work on whatever they
want; and they certainly don't have minions employed to do all of the
grunt work to support code maintenance work, especially if we let
crappy code slip past us in the name of "time to market" concerns.)

So I think we'll get past this.  It might take some more effort, and
more trust building --- on both sides --- but I'm fairly optismistic
that it will happen.  It might not happe as *fast* as people might
like; as Linus pointed out, it took ten years for the Clang compiler
to be considered 100% fully supported --- and this was without needing
to worrying about language issues, including an upstream language
community which refuses to make any kind of backwards compatibility
guarantees, and which is *actively* hostile to a second Rust compiler
implementation (I suspect because it might limit their ability to make
arbitrary backwards-incompatble language changes).

> Obviously respect and open-mindedness to new ideas appears to be the
> grease that makes all of this run smoothly.  Unfortunately that seems
> to be about as rare a commodity as omniscience in our industry.

The other thing which is super rare is people and companies who care
about tech debt cleanup, code maintainability, and code quality.
Instead of complaining about maintainers for who are unreasonably
caring about these things, when they are desparately under-resourced
to do as good of a job as they industry demands, how about meeting us
half-way and *helping* us with these sort of long-term code health
issues?  Maybe if you engage us as part of the community, we'll be a
lot more open to adding changes that might increase the code
maintenance burden?

Cheers,

					- Ted

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

[Danilo Krummrich]

Ted,

On Sat, Feb 08, 2025 at 03:44:16PM -0500, Theodore Ts'o wrote:
> This was the trust of my "Beyond Upstream First" presentation which I
> gave to the Linux Foundation Member Summit last fall[1].
> 
> [1] https://docs.google.com/presentation/d/11rMc8PBeyMItV6hv31OHSZ626_6FCZxjX6ZxEAehCpQ/edit#slide=id.p
> 
> Now, I'll say that the Rust developers are making strides in the right
> direction here.

Please let me add that a lot of those Rust kernel developers also have been
kernel developers before there has been Rust in the kernel and do still
contribute and even maintain C components, drivers and / or subsystems.

I think missing trust should not be a relevent factor in this matter.

> Miguel has stood for election for the Technical
> Adviory Board, and has been contributing in various ways beyond just
> Rust for Linux.

Thanks for pointing this out.

- Danilo

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

[David Airlie]

On Sun, Feb 9, 2025 at 6:48 AM Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
> >
> > The all powerful sub-system maintainer model works well if the big
> > technology companies can employ omniscient individuals in these roles,
> > but those types are a bit hard to come by.
>
> I'll let you in a secret.  The maintainers are not "all-powerfui".  We
> are the "thin blue line" that is trying to keep the code to be
> maintainable and high quality.  Like most leaders of volunteer
> organization, whether it is the Internet Engineerint Task Force (the
> standards body for the Internet), we actually have very little power.
> We can not *command* people to work on retiring technical debt, or to
> improve testing infrastructure, or work on some particular feature
> that we'd very like for our users.

Just as a courtesy to others can we not use the "thin blue line"
analogy in this community, it has had some bad connotation thrown on
it in the US context over the past few years, and I'd rather not as a
maintainer be aligned with current connotation/interpretations of it,
despite having family involved in our local force.

I'm open to suggestions for any better analogies.

Dave.

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

[Simona Vetter]

On Thu, Feb 13, 2025 at 08:20:52PM +1000, David Airlie wrote:
> On Sun, Feb 9, 2025 at 6:48 AM Theodore Ts'o <tytso@mit.edu> wrote:
> >
> > On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
> > >
> > > The all powerful sub-system maintainer model works well if the big
> > > technology companies can employ omniscient individuals in these roles,
> > > but those types are a bit hard to come by.
> >
> > I'll let you in a secret.  The maintainers are not "all-powerfui".  We
> > are the "thin blue line" that is trying to keep the code to be
> > maintainable and high quality.  Like most leaders of volunteer
> > organization, whether it is the Internet Engineerint Task Force (the
> > standards body for the Internet), we actually have very little power.
> > We can not *command* people to work on retiring technical debt, or to
> > improve testing infrastructure, or work on some particular feature
> > that we'd very like for our users.
> 
> Just as a courtesy to others can we not use the "thin blue line"
> analogy in this community, it has had some bad connotation thrown on
> it in the US context over the past few years, and I'd rather not as a
> maintainer be aligned with current connotation/interpretations of it,
> despite having family involved in our local force.

Agreed. I dropped a bit the ball on this, because at first I thought this
was only posted on part of the thread that wasn't cc'ed to dri-devel - I
can't pick a fight with the kernel community at large for everything that
happens. And then I let Dave handle this, because I couldn't come up with
anything that's not a nuclear table flip. 2 weeks later I'm still not
better, so let me instead express positively what kind of maintainership I
strive for by linking to an old talk of mine:

https://blog.ffwll.ch/2017/01/maintainers-dont-scale.html

> I'm open to suggestions for any better analogies.

Better analogy aside, I fundamentally disagree with understanding
maintainership as a gatekeeper role that exists to keep the chaos out. My
goal is to help build a community where people enjoy collaborating, and
then gtfo so I don't hinder them. I think the talk I linked above is
holding up quite well even years later, but the last part really embodies
that idea, so let me just quote that:

    Be a Steward, Not a Lord

    I think one of key advantages of open source is that people stick
    around for a very long time. Even when they switch jobs or move
    around. Maybe the usual “for life” qualifier isn’t really a great
    choice, since it sounds more like a mandatory sentence than something
    done by choice. What I object to is the “dictator” part, since if your
    goal is to grow a great community and maybe reach world domination,
    then you as the maintainer need to serve that community. And not that
    the community serves you.

Cheers, Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[Jason Gunthorpe]

On Thu, Feb 20, 2025 at 05:24:01PM +0100, Simona Vetter wrote:
> Better analogy aside, I fundamentally disagree with understanding
> maintainership as a gatekeeper role that exists to keep the chaos out. My
> goal is to help build a community where people enjoy collaborating, and
> then gtfo so I don't hinder them. I think the talk I linked above is
> holding up quite well even years later, but the last part really embodies
> that idea, so let me just quote that:
> 
>     Be a Steward, Not a Lord
> 
>     I think one of key advantages of open source is that people stick
>     around for a very long time. Even when they switch jobs or move
>     around. Maybe the usual “for life” qualifier isn’t really a great
>     choice, since it sounds more like a mandatory sentence than something
>     done by choice. What I object to is the “dictator” part, since if your
>     goal is to grow a great community and maybe reach world domination,
>     then you as the maintainer need to serve that community. And not that
>     the community serves you.

+1

I agree and try, as best I can, to embody this.

Jason

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

[Jarkko Sakkinen]

On Thu, 2025-02-20 at 12:37 -0400, Jason Gunthorpe wrote:
> >     I think one of key advantages of open source is that people
> > stick
> >     around for a very long time. Even when they switch jobs or move
> >     around. Maybe the usual “for life” qualifier isn’t really a
> > great
> >     choice, since it sounds more like a mandatory sentence than
> > something
> >     done by choice. What I object to is the “dictator” part, since
> > if your
> >     goal is to grow a great community and maybe reach world
> > domination,
> >     then you as the maintainer need to serve that community. And
> > not that
> >     the community serves you.
> 
> +1
> 
> I agree and try, as best I can, to embody this.

I keep four simple rules of email response list these days when
I response to LKML:

1. Be honest.
2. Address your concerns.
3. Ask for help where you need it.
4. Admit your possible misconceptions (getting things wrong is not a mistake).

It's quite easy actually shift away from these even if you
don't do it purposely. So I actually just read what I'm going
to respond and reflect to these :-) It's anyhow usually best
to keep a short break and breath-in/outs before triggering
send, right?

The fourth one addresses so called "toxic positive" responses
as addresses in the associated Mastodon thread [1] :-)

> Jason

[1] https://social.kernel.org/notice/ArH99Q2ErS20vJB7Tc

BR, Jarkko

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

[Ronja Meyer]

On 08.02.2025 21:44, Theodore Ts'o wrote:
> I'll let you in a secret.  The maintainers are not "all-powerfui".  We
> are the "thin blue line" that is trying to keep the code to be
> maintainable and high quality.  Like most leaders of volunteer
> organization, whether it is the Internet Engineerint Task Force (the
> standards body for the Internet), we actually have very little power.
 > […] structurelessness becomes a way of masking power, and […] is 
usually most strongly advocated by those who are the most powerful 
(whether they are conscious of their power or not). As long as the 
structure of the group is informal, the rules of how decisions are made 
are known only to a few and awareness of power is limited to those who 
know the rules. Those who do not know the rules and are not chosen for 
initiation must remain in confusion, or suffer from paranoid delusions 
that something is happening of which they are not quite aware. […]

 From "The Tyranny of Structurelessness", written by Jo Freeman in 1970. 
https://www.jofreeman.com/joreen/tyranny.htm

- Ronja

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

[33KK]

Honestly, how about you accept the fact that maybe the problem is you?

You're not doing any good by just scolding Hector for "social media 
brigading"
and not addressing the core issue, especially considering that LKML 
drama always
ends up on social media and on reaction content farms anyway, without the
"brigading", and Hector wasn't the one who started the drama.

You can't expect people to just keep going on and on in circular 
conversations
on the mailing list with somebody who isn't even engaging in good faith. 
These
conversations are about as technical as high school bullying, with you 
being the
teacher who punishes the one who tried to speak out, because they didn't 
want to
deal with figuring out who is right or wrong, and the victim is trying their
best to work out a solution for an unsolvable problem, since there's no 
solution
that the other side would accept.

Obviously, the people involved are tired of having this shit show happen 
again and
again and of course they will end up going to vent on social media, 
break down,
or leave, since they're not heard on the mailing list, and their mental 
health,
time and energy is clearly not respected by any of the adults present in the
room, judging by the complete inaction on the part of Linux's leadership.

You can't just pretend that multiple people leaving because of this is not a
problem. You can't just have people burn their time, energy and mental 
health on
pointless "discussions" and end up burning out, breaking down or leaving 
instead
of getting anything done. You can't just keep having your maintainers 
break down
one after another. This is not normal. This is not healthy. The process 
isn't
"working".

Just letting these "discussions" keep playing out like this is terrible
leadership, and is clearly not working well for mental health of people 
trying
to get involved with Linux.

You either want the R4L project to succeed and have new maintainers want 
to get
involved with the project, and you tell the hostile C maintainers to 
shut up and
cope with it, or you want the R4L project to fail and constantly have these
pointless "discussions" which boil down to some out of touch maintainer 
bullying
someone about something that should've been resolved long ago.

And as far as the *barely* technical arguments in the thread go:

The code is clearly exactly where it should be, in rust/kernel/dma, 
where else
is this supposed to go? Duplicating the bindings in multiple drivers 
would just
make the situation much worse, since now you have to worry about breaking
multiple copies of the bindings. R4L also proposed that they will 
maintain the
bindings.

Is the minor inconvenience of another maintainer having to review breaking
changes to DMA interfaces or some similar process to prevent build breakages
such a big deal compared to the pretty significant benefits Rust 
provides? The
Rust-based drivers were developed very quickly and ended up being way 
extremely
stable with relatively little effort compared to writing the same driver 
in C.

I think the benefits are pretty clear, if you can write a driver without
spending most of the time barely managing to tracking memory ownership 
in your
head, making sure you're not misusing underdocumented kernel APIs, etc.
obviously you're going to be significantly more productive, and it's 
also easier
for a new maintainer to get involved, since it's harder to break something.
Also, when writing safe bindings you have to double-check the safety of 
the API,
which helps to notice unsoundness in the C interface itself.

 > The only reason Linux managed to survive so long is by not having 
internal
 > boundaries

The actual reason Linux managed to survive so long is because of people 
working
together. Nobody understands the entirety of the kernel source, 
maintenance of
subsystems is split between different people that work together. What 
Christoph
is doing here, is pretty much opposite of that. He is actively trying to 
prevent
R4L from writing bindings to DMA, which are crucial to the project. 
Effectively
saying that the project should just go away entirely.

Christoph pretty clearly has no valid argument here.


NOTE: I am not affiliated in any way with R4L or Linux maintainers, I'm 
just a
Linux user watching this shitshow unfold, and am very disappointed about how
it's being handled.

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

[Danilo Krummrich]

On Thu, Feb 06, 2025 at 06:19:42PM +0900, Hector Martin wrote:
> 
> If shaming on social media does not work, then tell me what does,

Most importantly be *consistent* with good technical arguments, calmly focus on
your actual matter rather than escalating any surrounding details.

Accept that sometimes things can't be reached directly, but additional work is
needed to change the preconditions.

Goals aren't reached by burning bridges, but by building them. Sometimes you
may not be able to build a bridge where you would like to. But you can still
look for alternative routes with and within the community.

Surely, it does take time and energy, but certainly there's no shortcut.

- Danilo

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

[Hector Martin]

On 2025/02/07 4:37, Danilo Krummrich wrote:
> On Thu, Feb 06, 2025 at 06:19:42PM +0900, Hector Martin wrote:
>>
>> If shaming on social media does not work, then tell me what does,
> 
> Most importantly be *consistent* with good technical arguments, calmly focus on
> your actual matter rather than escalating any surrounding details.
> 
> Accept that sometimes things can't be reached directly, but additional work is
> needed to change the preconditions.
> 
> Goals aren't reached by burning bridges, but by building them. Sometimes you
> may not be able to build a bridge where you would like to. But you can still
> look for alternative routes with and within the community.
> 
> Surely, it does take time and energy, but certainly there's no shortcut.

I'm not talking about individual technical problems. You cannot solve
social and community problems with technical arguments.

Yes, given enough patience and technical argumentation, you can get code
into the kernel, or maybe even get some existing code refactored. That
doesn't change the fact that the process is often quite terrible,
hostile to newcomers, demoralizing, and by wide consensus much worse
than practically any other FOSS project, even those of similar scope to
the kernel.

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).

But I've used up all my spoons for this, and clearly Linus doesn't think
there's a problem in this thread worth replying to other than myself, so
I'm giving up on fighting for any change or being part of the kernel
maintainer community. Whether the rest of the kernel community chooses
to continue to live in an ugly bubble or actually try to fix some of
these systemic issues, is up to them.

- Hector

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

[Konstantin Ryabitsev]

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

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

[Hector Martin]

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.

There's also the fact that there is enough support for Linux that
finding a Benevolent Entity to provide stuff like DDoS protection is not
particularly hard, and such services are easily replaceable should
priorities change (and indeed are the kind of service that can only be
provided by a large entity, whether paid or sponsored, by nature). Heck,
even I have a Benevolent Entity sponsoring a CDN frontend for Asahi
sites and installer images (bunny.net, they're nice, highly recommended).

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.
The kernel already survived the great BitKeeper to Git migration, and
this time there's no proprietary software to be yanked out from under
the kernel (at least assuming the forge of choice is FOSS and
self-hostable, which seems like a no-brainer given the concerns). As
long as everyone has the Git trees, infrastructure can be rebuilt. As
long as everyone has email and git, development can continue ad-hoc.
Sure, it would cause a blip, but it's not like we would switch to a
forge, the forge would go down for a few days, and it would not be the
end of the world. Just ask the freedesktop folks (a good case study on
how infra is hard, but not impossible, and even if imperfect, even if at
times frustrating, it still functions, and well enough to still be
wildly positive compared to not having that infra at all).

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.

All that said, thanks for b4. I might have given up much earlier, not
due to flamewars but due to exhaustion with poor tooling, if it didn't
exist.

- Hector

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

[Konstantin Ryabitsev]

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.

> 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.

> 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.

> All that said, thanks for b4. I might have given up much earlier, not
> due to flamewars but due to exhaustion with poor tooling, if it didn't
> exist.

I'm happy to hear that.

Best wishes,
-K

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On Sun, Feb 09, 2025 at 03:25:26AM -0500, Neal Gompa wrote:
> On Friday, February 7, 2025 1:16:11 PM Eastern Standard Time Konstantin 
> Ryabitsev wrote:

> > 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.

We do actually have some people using forges already, for example the
SOF people do a bunch of their review on github and then turn that into
patch serieses which they send via the normal email route when they're
happy with them.  I think tree wide stuff flows in via back merges or
rebases, one of the benefits of delegation is that it's not my problem.
This all works perfectly well from my side, as far as I know it's fine
for the SOF people too.  It certainly doesn't seem insurmountable.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Neal Gompa]

On Mon, Feb 10, 2025 at 12:28 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Sun, Feb 09, 2025 at 03:25:26AM -0500, Neal Gompa wrote:
> > On Friday, February 7, 2025 1:16:11 PM Eastern Standard Time Konstantin
> > Ryabitsev wrote:
>
> > > 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.
>
> We do actually have some people using forges already, for example the
> SOF people do a bunch of their review on github and then turn that into
> patch serieses which they send via the normal email route when they're
> happy with them.  I think tree wide stuff flows in via back merges or
> rebases, one of the benefits of delegation is that it's not my problem.
> This all works perfectly well from my side, as far as I know it's fine
> for the SOF people too.  It certainly doesn't seem insurmountable.

It might be working as long as a subsystem continues to allow
receiving patches via email. As soon as a subsystem decides to stop
doing that (which is absolutely their right given the model of
subsystem maintenance that the Linux project has), I think this will
break down very quickly.

I wonder which team will be the first one to do it. It's not a
question of if, but when.


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

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

[Al Viro]

On Fri, Feb 14, 2025 at 02:10:57AM -0500, Neal Gompa wrote:
> On Mon, Feb 10, 2025 at 12:28 PM Mark Brown <broonie@kernel.org> wrote:
> >
> > On Sun, Feb 09, 2025 at 03:25:26AM -0500, Neal Gompa wrote:
> > > On Friday, February 7, 2025 1:16:11 PM Eastern Standard Time Konstantin
> > > Ryabitsev wrote:
> >
> > > > 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.
> >
> > We do actually have some people using forges already, for example the
> > SOF people do a bunch of their review on github and then turn that into
> > patch serieses which they send via the normal email route when they're
> > happy with them.  I think tree wide stuff flows in via back merges or
> > rebases, one of the benefits of delegation is that it's not my problem.
> > This all works perfectly well from my side, as far as I know it's fine
> > for the SOF people too.  It certainly doesn't seem insurmountable.
> 
> It might be working as long as a subsystem continues to allow
> receiving patches via email. As soon as a subsystem decides to stop
> doing that (which is absolutely their right given the model of
> subsystem maintenance that the Linux project has), I think this will
> break down very quickly.
> 
> I wonder which team will be the first one to do it. It's not a
> question of if, but when.

Then it will be a matter of patches affecting their subtree getting merged
through the mainline.  All there is to it...

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

On Fri, Feb 14, 2025 at 02:10:57AM -0500, Neal Gompa wrote:
> On Mon, Feb 10, 2025 at 12:28 PM Mark Brown <broonie@kernel.org> wrote:

> > We do actually have some people using forges already, for example the
> > SOF people do a bunch of their review on github and then turn that into
> > patch serieses which they send via the normal email route when they're
> > happy with them.  I think tree wide stuff flows in via back merges or
> > rebases, one of the benefits of delegation is that it's not my problem.
> > This all works perfectly well from my side, as far as I know it's fine
> > for the SOF people too.  It certainly doesn't seem insurmountable.

> It might be working as long as a subsystem continues to allow
> receiving patches via email. As soon as a subsystem decides to stop
> doing that (which is absolutely their right given the model of
> subsystem maintenance that the Linux project has), I think this will
> break down very quickly.

Eh, probably they'll just get bypassed for the affected patches if they
really just drop everything on the floor.  That's effectively what's
happening with SOF in that I take patches for it (which seems to work
for everyone, people do review stuff that comes in on the list).  That
tends to be what happens if people are unresponsive.  More likely
there'f be some bridging effort of some kind with pressure applied to
get substantial work done on the forge.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Linus Torvalds]

On Fri, 7 Feb 2025 at 10:02, Hector Martin <marcan@marcan.st> wrote:
>
> Meanwhile, for better or worse, much of Linux infra *is* centralized -
> for example, the mailing lists themselves, and a lot of the Git hosting.

The mailing lists are mostly on kernel.org, but the git hosting most
certainly is not centralized in any way.

The kernel.org git repositories used to be special in that I didn't
require signed tags for them, because I trusted the user maintenance.
But I was encouraging signed tags even back then, and once it got to
the point where most were signed anyway, I just made it a rule. So now
kernel.org isn't special even in that respect.

Now, kernel.org is very much _convenient_. And you see that in the
stats: of my pulls in the last year, 85% have been from kernel.org.
But that is very much because it is convenient, not because it's
centralized.

But that still leaves the 15% that aren't kernel.org.

Since I did the stats, in case anybody is interested, the top
non-kernel.org hosts for my pulls are github.com, git.samba.org,
gitlab.freedesktop.org, evilpiepirate.org, git.infradead.org and
git.lwn.net (and there's a handful of other ones in there).

(And while I did the stats just for *my* pulls, if you look at total
merges over-all, the non-korg repositories are actually at 20% - I
think my percentages are higher simply because I tend to pull from
mostly top-level maintainers, and those are even more likely to use a
kernel.org account).

More importtantly, not being centralized was very much a basic tenet
of git, so *if* git.kernel.org were to become problematic, it's very
easy to move git repositories anywhere else. Very much by design.

              Linus

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

[Hector Martin]

On 2025/02/08 3:33, Linus Torvalds wrote:
> On Fri, 7 Feb 2025 at 10:02, Hector Martin <marcan@marcan.st> wrote:
>>
>> Meanwhile, for better or worse, much of Linux infra *is* centralized -
>> for example, the mailing lists themselves, and a lot of the Git hosting.
> 
> The mailing lists are mostly on kernel.org, but the git hosting most
> certainly is not centralized in any way.
> 
> The kernel.org git repositories used to be special in that I didn't
> require signed tags for them, because I trusted the user maintenance.
> But I was encouraging signed tags even back then, and once it got to
> the point where most were signed anyway, I just made it a rule. So now
> kernel.org isn't special even in that respect.
> 
> Now, kernel.org is very much _convenient_. And you see that in the
> stats: of my pulls in the last year, 85% have been from kernel.org.
> But that is very much because it is convenient, not because it's
> centralized.
> 
> But that still leaves the 15% that aren't kernel.org.

For all intents and purposes, 85% centralized might as well be fully
centralized. That is, any downtime on kernel.org will affect the
community effectively the same as downtime on a true central SPOF would.

> More importtantly, not being centralized was very much a basic tenet
> of git, so *if* git.kernel.org were to become problematic, it's very
> easy to move git repositories anywhere else. Very much by design.

And this is why, over focus on *decentraliation*, I think we should be
focusing on *recoverability* and *data availability*.

There are two distinct scenarios. If kernel.org goes down for a while,
that screws with people's workflow. They can find alternatives, but it
will cause immediate, acute disruption, even while using "decentralized"
git. You still need to tell people where the new repos are, reconfigure
remotes, etc.. If the disruption is expected to be short-lived, a lot of
people will choose to just ride it out, rather than find alternatives,
or will only use alternatives in an ad-hoc manner where strictly
necessary. Nobody does a "true" complete migration to another Git
hosting when faced with a brief, temporary outage (heck, even just the
time it takes to push a Linux Git tree from scratch to somewhere new is
much longer than ideal, more so if your internet connection isn't the
best or the routing to the server in question isn't great). At most you
push whatever you're working on as needed somewhere else.

If kernel.org goes down permanently or long term (or becomes
problematic), that's when you start doing a full migration. And thanks
to the Git design, this is possible - not because it's decentralized per
se, but because everyone has local copies of almost everything, and they
can easily be restored onto a new service.

The same goes for a forge scenario. If it goes down briefly, you fix it,
and you can still use email to communicate with people ad hoc and send
git changes around through any other hosting. It's still Git at the end
of the day. Emailed patches and Git trees aren't going to become
unusable just because most or all of the regular development happens on
a forge.

And if it goes down permanently or long term, or becomes problematic,
what really matters isn't that it's "decentralized" as in federation.
It's that the data is available, in much the same way it is for
lore.kernel.org, and that people are actively backing it up (and it
isn't hard to arrange for a handful of folks/organizations to have up to
date mirrors, you don't need a Git-like scenario where literally
everyone has full repo dumps; heck, I have a big NAS at home, I'd
volunteer myself). Then, the service can be restored elsewhere when
needed. If the issue is with the specific forge software used, you can
always develop a migration plan to a different software (which, if the
risk is managed properly, shouldn't be a time-critical process anyway).

- Hector

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

[Dr. David Alan Gilbert]

* Hector Martin (marcan@marcan.st) 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   |_______/

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

[Hector Martin]

On 2025/02/06 3:52, Simona Vetter wrote:
> On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
>> Adding Linus
>>
>> My 2c: If Linus doesn't pipe up with an authoritative answer to this
>> thread, Miguel and the other Rust folks should just merge this series
>> once it is reviewed and ready, ignoring Christoph's overt attempt at
>> sabotaging the project. If Linus pulls it, what Christoph says doesn't
>> matter. If Linus doesn't pull it, the R4L project is essentially dead
>> until either Linus or Christoph make a move. Everything else is beating
>> around the bush.
>>
>> Rust folks: Please don't waste your time and mental cycles on drama like
>> this. It's not worth your time. Either Linus likes it, or he doesn't.
>> Everything else is distractions orchestrated by a subset of saboteur
>> maintainers who are trying to demoralize you until you give up, because
>> they know they're going to be on the losing side of history sooner or
>> later. No amount of sabotage from old entrenched maintainers is going to
>> stop the world from moving forward towards memory-safe languages.
>>
>> FWIW, in my opinion, the "cancer" comment from Christoph would be enough
>> to qualify for Code-of-Conduct action, but I doubt anything of the sort
>> will happen.
> 
> Yeah no.
> 
> https://chaos.social/@sima/113942119012147959
> 
> This was about you, because typing a proper answer takes a bit longer. It
> was also about your toots on fedi, like this:
> 
> https://social.treehouse.systems/@marcan/113941468353031993
> 
> And "haha it's only a joke" does not work with your public profile and following.
> 
> I do understand the frustration and temptation to just burn it all to the
> ground, head the call of the sirens, or maybe for me more pick up goat
> farming in the Swiss Alps. But you can't have it both and expect to also
> be part of and contribute to the same community. And personally I don't
> appreciate getting drenched in gasoline while I'm trying to quench flames
> on the ground.
> 
> And this isn't the first time or the second, by now it's a pretty clear
> pattern over some years. And with the first I could explain why you react
> like that and you had my full understanding, but eventually that runs a
> bit thin as an excuse.  Now I'm left with the unlikely explanation that
> you just like thundering in as the cavalry, fashionably late, maximally
> destructive, because it entertains the masses on fedi or reddit or
> wherever. I have no idea what you're trying to achieve here, I really
> don't get it, but I am for sure fed up dealing with the fallout.
> 
> Cheers, Sima

Since we're into complaining about social media posts on the list now,
I'm going to link one of yours:

https://chaos.social/@sima/113961496955043901

An R4L maintainer quit after multiple rounds of hostility, including
some completely unacceptable public comments bordering on downright
harassment from tytso, a situation which was widely publicized.

If, according to you, that's "shockingly smooth" with "no outsized
drama" other than "what I stirred up" (I guess you also missed the whole
LWN post about this thread before I posted anything on Fedi? That's how
I even found out about this), then I'm glad I'm disengaging with this
community. The Stockholm syndrome and utter denial is palpable.

I thought I could work with you on these issues; I don't know what
happened over the past year since we last had a private conversation
about this, but clearly you've changed your mind.

Thus, as you kindly requested of me in social media,

https://chaos.social/@sima/113961283260455876

I will now proceed to fuck off. Good luck.

- Hector

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

[Hector Martin]

On 2025/02/07 18:41, Hector Martin wrote:
> On 2025/02/06 3:52, Simona Vetter wrote:
>> On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
>>> Adding Linus
>>>
>>> My 2c: If Linus doesn't pipe up with an authoritative answer to this
>>> thread, Miguel and the other Rust folks should just merge this series
>>> once it is reviewed and ready, ignoring Christoph's overt attempt at
>>> sabotaging the project. If Linus pulls it, what Christoph says doesn't
>>> matter. If Linus doesn't pull it, the R4L project is essentially dead
>>> until either Linus or Christoph make a move. Everything else is beating
>>> around the bush.
>>>
>>> Rust folks: Please don't waste your time and mental cycles on drama like
>>> this. It's not worth your time. Either Linus likes it, or he doesn't.
>>> Everything else is distractions orchestrated by a subset of saboteur
>>> maintainers who are trying to demoralize you until you give up, because
>>> they know they're going to be on the losing side of history sooner or
>>> later. No amount of sabotage from old entrenched maintainers is going to
>>> stop the world from moving forward towards memory-safe languages.
>>>
>>> FWIW, in my opinion, the "cancer" comment from Christoph would be enough
>>> to qualify for Code-of-Conduct action, but I doubt anything of the sort
>>> will happen.
>>
>> Yeah no.
>>
>> https://chaos.social/@sima/113942119012147959
>>
>> This was about you, because typing a proper answer takes a bit longer. It
>> was also about your toots on fedi, like this:
>>
>> https://social.treehouse.systems/@marcan/113941468353031993
>>
>> And "haha it's only a joke" does not work with your public profile and following.
>>
>> I do understand the frustration and temptation to just burn it all to the
>> ground, head the call of the sirens, or maybe for me more pick up goat
>> farming in the Swiss Alps. But you can't have it both and expect to also
>> be part of and contribute to the same community. And personally I don't
>> appreciate getting drenched in gasoline while I'm trying to quench flames
>> on the ground.
>>
>> And this isn't the first time or the second, by now it's a pretty clear
>> pattern over some years. And with the first I could explain why you react
>> like that and you had my full understanding, but eventually that runs a
>> bit thin as an excuse.  Now I'm left with the unlikely explanation that
>> you just like thundering in as the cavalry, fashionably late, maximally
>> destructive, because it entertains the masses on fedi or reddit or
>> wherever. I have no idea what you're trying to achieve here, I really
>> don't get it, but I am for sure fed up dealing with the fallout.
>>
>> Cheers, Sima
> 
> Since we're into complaining about social media posts on the list now,
> I'm going to link one of yours:
> 
> https://chaos.social/@sima/113961496955043901
> 
> An R4L maintainer quit after multiple rounds of hostility, including
> some completely unacceptable public comments bordering on downright
> harassment from tytso, a situation which was widely publicized.
> 
> If, according to you, that's "shockingly smooth" with "no outsized
> drama" other than "what I stirred up" (I guess you also missed the whole
> LWN post about this thread before I posted anything on Fedi? That's how
> I even found out about this), then I'm glad I'm disengaging with this
> community. The Stockholm syndrome and utter denial is palpable.
> 
> I thought I could work with you on these issues; I don't know what
> happened over the past year since we last had a private conversation
> about this, but clearly you've changed your mind.
> 
> Thus, as you kindly requested of me in social media,
> 
> https://chaos.social/@sima/113961283260455876
> 
> I will now proceed to fuck off. Good luck.

Oh, and one last thing. I've heard that, in whatever backroom
conversations you've been having about this situation, there has
apparently been a belief, explicit or implicit, that I am in any way
employed to work on the Linux kernel.

Unlike most people in this thread, I don't enjoy the luxury of a cushy
tech job that pays me to deal with this community. I am supported
exclusively by donations, which incidentally, have been steadily
*de*creasing since the start of the Asahi Linux project. The project has
zero corporate sponsorship.

And I do believe the fact that essentially all high-level Linux kernel
maintainers and contributors are paid by corporations to do it is a
major factor that has caused this community to become wildly out of
touch with what it means to be a community FOSS project.

- Hector

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

[Greg KH]

On Fri, Feb 07, 2025 at 07:20:03PM +0900, Hector Martin wrote:
> And I do believe the fact that essentially all high-level Linux kernel
> maintainers and contributors are paid by corporations to do it is a
> major factor that has caused this community to become wildly out of
> touch with what it means to be a community FOSS project.

Please note, that ever since I started keeping track of this type of
thing, way back in 2003 or so, it has been the case that over 80% of the
contributions come from company-funded developers.  Which means it
really goes back before that as well.

And that's good, it means that we have backing to do this properly, from
the companies that benifit from it.  To not have that would make it much
harder for any of this to work properly at all.

So don't try to play the "you all work for companies" card, that isn't
going to fly as obviously we all speak for ourselves here, and our
companies _know_ they can't tell us what to do, but they give us insight
into the problems that they have with Linux in order for us to help
change it to make it better for everyone.

Because again, everyone has the same problems (individuals and
companies), and so solving it for one "group", solves it for everyone.

thanks,

greg k-h

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

[Simona Vetter]

On Fri, Feb 07, 2025 at 07:20:03PM +0900, Hector Martin wrote:
> On 2025/02/07 18:41, Hector Martin wrote:
> > On 2025/02/06 3:52, Simona Vetter wrote:
> >> On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
> >>> Adding Linus
> >>>
> >>> My 2c: If Linus doesn't pipe up with an authoritative answer to this
> >>> thread, Miguel and the other Rust folks should just merge this series
> >>> once it is reviewed and ready, ignoring Christoph's overt attempt at
> >>> sabotaging the project. If Linus pulls it, what Christoph says doesn't
> >>> matter. If Linus doesn't pull it, the R4L project is essentially dead
> >>> until either Linus or Christoph make a move. Everything else is beating
> >>> around the bush.
> >>>
> >>> Rust folks: Please don't waste your time and mental cycles on drama like
> >>> this. It's not worth your time. Either Linus likes it, or he doesn't.
> >>> Everything else is distractions orchestrated by a subset of saboteur
> >>> maintainers who are trying to demoralize you until you give up, because
> >>> they know they're going to be on the losing side of history sooner or
> >>> later. No amount of sabotage from old entrenched maintainers is going to
> >>> stop the world from moving forward towards memory-safe languages.
> >>>
> >>> FWIW, in my opinion, the "cancer" comment from Christoph would be enough
> >>> to qualify for Code-of-Conduct action, but I doubt anything of the sort
> >>> will happen.
> >>
> >> Yeah no.
> >>
> >> https://chaos.social/@sima/113942119012147959
> >>
> >> This was about you, because typing a proper answer takes a bit longer. It
> >> was also about your toots on fedi, like this:
> >>
> >> https://social.treehouse.systems/@marcan/113941468353031993
> >>
> >> And "haha it's only a joke" does not work with your public profile and following.
> >>
> >> I do understand the frustration and temptation to just burn it all to the
> >> ground, head the call of the sirens, or maybe for me more pick up goat
> >> farming in the Swiss Alps. But you can't have it both and expect to also
> >> be part of and contribute to the same community. And personally I don't
> >> appreciate getting drenched in gasoline while I'm trying to quench flames
> >> on the ground.
> >>
> >> And this isn't the first time or the second, by now it's a pretty clear
> >> pattern over some years. And with the first I could explain why you react
> >> like that and you had my full understanding, but eventually that runs a
> >> bit thin as an excuse.  Now I'm left with the unlikely explanation that
> >> you just like thundering in as the cavalry, fashionably late, maximally
> >> destructive, because it entertains the masses on fedi or reddit or
> >> wherever. I have no idea what you're trying to achieve here, I really
> >> don't get it, but I am for sure fed up dealing with the fallout.
> >>
> >> Cheers, Sima
> > 
> > Since we're into complaining about social media posts on the list now,
> > I'm going to link one of yours:
> > 
> > https://chaos.social/@sima/113961496955043901
> > 
> > An R4L maintainer quit after multiple rounds of hostility, including
> > some completely unacceptable public comments bordering on downright
> > harassment from tytso, a situation which was widely publicized.
> > 
> > If, according to you, that's "shockingly smooth" with "no outsized
> > drama" other than "what I stirred up" (I guess you also missed the whole
> > LWN post about this thread before I posted anything on Fedi? That's how
> > I even found out about this), then I'm glad I'm disengaging with this
> > community. The Stockholm syndrome and utter denial is palpable.

Yes, the kernel's conduct is still not where I think it needs to be. And
there are still cases occuring with some regularity which would be
unacceptable on dri-devel and sanctioned under the freedesktop.org code of
conduct. But that's not really new, it's not really specific to the r4l
project, and despite that it's still not good enough, it's definitely much
better than 10 years ago.

That all aside, I put the "outsized" very intentionally in my comment. It
carries a lot more than just the above paragraph in just one small word.

> > I thought I could work with you on these issues; I don't know what
> > happened over the past year since we last had a private conversation
> > about this, but clearly you've changed your mind.

I got seriously annoyed with you about two years ago for the first time,
but kept chatting for quite a while longer. Nothing changed. Like I said,
I'm not complaining about this specific case here, but about a pattern
that you've established consistently over a fair amount of time.

And if you're wondering why you didn't realize this: It's impossible to
change people by telling them they're wrong. What does tend to work is
explaining different perspectives, so that they can figure it out
themselves. And sometimes that's just way too subtle to ever register.

> > Thus, as you kindly requested of me in social media,
> > 
> > https://chaos.social/@sima/113961283260455876
> > 
> > I will now proceed to fuck off. Good luck.

I wasn't fully awake yet this morning, but I have no issue standing behind
that thread in it's entirety. Lightly edited for typos below, with one
sentence added for a bit more context:

This isn't about "being civil" or "friendly" and even less about "don't
call out". This is about calling out in an ineffective and imprecise way,
so that the people actually trying to change things are busy patching up
your collateral damage instead of implementing real changes, while all
you've achieved is airing your frustration for internet drama points.

Aside from that I've learned through private feedback since my first mail
here that your social media brigading has had much more of a chilling
effect on contributors than I assumed, which is not acceptable.

When you're that harmful with your calling out, eventually I'm going to be
fed up, and you get a live round shot across your bow. And if that then
causes you to ragequit, because you can't actually deal with the heat
you've been dishing out coming back around the corner:

Fuck off.

Or as Dave Airlie put it upthread in this conversation:

"Being toxic on the right side of an argument is still toxic, [...]"

So please do call out broken things, do change things, I've been doing it
for well over a decade in the linux kernel. But do it in a way that you're
not just becoming part of the problem and making it bigger.

> Oh, and one last thing. I've heard that, in whatever backroom
> conversations you've been having about this situation, there has
> apparently been a belief, explicit or implicit, that I am in any way
> employed to work on the Linux kernel.
> 
> Unlike most people in this thread, I don't enjoy the luxury of a cushy
> tech job that pays me to deal with this community. I am supported
> exclusively by donations, which incidentally, have been steadily
> *de*creasing since the start of the Asahi Linux project. The project has
> zero corporate sponsorship.
> 
> And I do believe the fact that essentially all high-level Linux kernel
> maintainers and contributors are paid by corporations to do it is a
> major factor that has caused this community to become wildly out of
> touch with what it means to be a community FOSS project.

I'm really not in favor of chiding people for how they earn money, because
this world isn't fair and critizing people for how they get their bills
paid is generally not ok. But this is a bit too much to just let it slide.

It's fairly plausible that you need the social media brigading to generate
attention that you can convert into enough donations to support the asahi
project. But someone has to clean up the mess your shitstorms create, it's
sure not you, which means my and other people's mental health essentially
pay your bills. And I really do not appreciate that dynamic.

Cheers, Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[Hector Martin]

On 2025/02/07 22:49, Simona Vetter wrote:
> On Fri, Feb 07, 2025 at 07:20:03PM +0900, Hector Martin wrote:
>> On 2025/02/07 18:41, Hector Martin wrote:
>>> On 2025/02/06 3:52, Simona Vetter wrote:
>>>> On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
>>>>> Adding Linus
>>>>>
>>>>> My 2c: If Linus doesn't pipe up with an authoritative answer to this
>>>>> thread, Miguel and the other Rust folks should just merge this series
>>>>> once it is reviewed and ready, ignoring Christoph's overt attempt at
>>>>> sabotaging the project. If Linus pulls it, what Christoph says doesn't
>>>>> matter. If Linus doesn't pull it, the R4L project is essentially dead
>>>>> until either Linus or Christoph make a move. Everything else is beating
>>>>> around the bush.
>>>>>
>>>>> Rust folks: Please don't waste your time and mental cycles on drama like
>>>>> this. It's not worth your time. Either Linus likes it, or he doesn't.
>>>>> Everything else is distractions orchestrated by a subset of saboteur
>>>>> maintainers who are trying to demoralize you until you give up, because
>>>>> they know they're going to be on the losing side of history sooner or
>>>>> later. No amount of sabotage from old entrenched maintainers is going to
>>>>> stop the world from moving forward towards memory-safe languages.
>>>>>
>>>>> FWIW, in my opinion, the "cancer" comment from Christoph would be enough
>>>>> to qualify for Code-of-Conduct action, but I doubt anything of the sort
>>>>> will happen.
>>>>
>>>> Yeah no.
>>>>
>>>> https://chaos.social/@sima/113942119012147959
>>>>
>>>> This was about you, because typing a proper answer takes a bit longer. It
>>>> was also about your toots on fedi, like this:
>>>>
>>>> https://social.treehouse.systems/@marcan/113941468353031993
>>>>
>>>> And "haha it's only a joke" does not work with your public profile and following.
>>>>
>>>> I do understand the frustration and temptation to just burn it all to the
>>>> ground, head the call of the sirens, or maybe for me more pick up goat
>>>> farming in the Swiss Alps. But you can't have it both and expect to also
>>>> be part of and contribute to the same community. And personally I don't
>>>> appreciate getting drenched in gasoline while I'm trying to quench flames
>>>> on the ground.
>>>>
>>>> And this isn't the first time or the second, by now it's a pretty clear
>>>> pattern over some years. And with the first I could explain why you react
>>>> like that and you had my full understanding, but eventually that runs a
>>>> bit thin as an excuse.  Now I'm left with the unlikely explanation that
>>>> you just like thundering in as the cavalry, fashionably late, maximally
>>>> destructive, because it entertains the masses on fedi or reddit or
>>>> wherever. I have no idea what you're trying to achieve here, I really
>>>> don't get it, but I am for sure fed up dealing with the fallout.
>>>>
>>>> Cheers, Sima
>>>
>>> Since we're into complaining about social media posts on the list now,
>>> I'm going to link one of yours:
>>>
>>> https://chaos.social/@sima/113961496955043901
>>>
>>> An R4L maintainer quit after multiple rounds of hostility, including
>>> some completely unacceptable public comments bordering on downright
>>> harassment from tytso, a situation which was widely publicized.
>>>
>>> If, according to you, that's "shockingly smooth" with "no outsized
>>> drama" other than "what I stirred up" (I guess you also missed the whole
>>> LWN post about this thread before I posted anything on Fedi? That's how
>>> I even found out about this), then I'm glad I'm disengaging with this
>>> community. The Stockholm syndrome and utter denial is palpable.
> 
> Yes, the kernel's conduct is still not where I think it needs to be. And
> there are still cases occuring with some regularity which would be
> unacceptable on dri-devel and sanctioned under the freedesktop.org code of
> conduct. But that's not really new, it's not really specific to the r4l
> project, and despite that it's still not good enough, it's definitely much
> better than 10 years ago.
> 
> That all aside, I put the "outsized" very intentionally in my comment. It
> carries a lot more than just the above paragraph in just one small word.
> 
>>> I thought I could work with you on these issues; I don't know what
>>> happened over the past year since we last had a private conversation
>>> about this, but clearly you've changed your mind.
> 
> I got seriously annoyed with you about two years ago for the first time,
> but kept chatting for quite a while longer. Nothing changed. Like I said,
> I'm not complaining about this specific case here, but about a pattern
> that you've established consistently over a fair amount of time.
> 
> And if you're wondering why you didn't realize this: It's impossible to
> change people by telling them they're wrong. What does tend to work is
> explaining different perspectives, so that they can figure it out
> themselves. And sometimes that's just way too subtle to ever register.
> 
>>> Thus, as you kindly requested of me in social media,
>>>
>>> https://chaos.social/@sima/113961283260455876
>>>
>>> I will now proceed to fuck off. Good luck.
> 
> I wasn't fully awake yet this morning, but I have no issue standing behind
> that thread in it's entirety. Lightly edited for typos below, with one
> sentence added for a bit more context:
> 
> This isn't about "being civil" or "friendly" and even less about "don't
> call out". This is about calling out in an ineffective and imprecise way,
> so that the people actually trying to change things are busy patching up
> your collateral damage instead of implementing real changes, while all
> you've achieved is airing your frustration for internet drama points.
> 
> Aside from that I've learned through private feedback since my first mail
> here that your social media brigading has had much more of a chilling
> effect on contributors than I assumed, which is not acceptable.
> 
> When you're that harmful with your calling out, eventually I'm going to be
> fed up, and you get a live round shot across your bow. And if that then
> causes you to ragequit, because you can't actually deal with the heat
> you've been dishing out coming back around the corner:
> 
> Fuck off.
> 
> Or as Dave Airlie put it upthread in this conversation:
> 
> "Being toxic on the right side of an argument is still toxic, [...]"
> 
> So please do call out broken things, do change things, I've been doing it
> for well over a decade in the linux kernel. But do it in a way that you're
> not just becoming part of the problem and making it bigger.
> 
>> Oh, and one last thing. I've heard that, in whatever backroom
>> conversations you've been having about this situation, there has
>> apparently been a belief, explicit or implicit, that I am in any way
>> employed to work on the Linux kernel.
>>
>> Unlike most people in this thread, I don't enjoy the luxury of a cushy
>> tech job that pays me to deal with this community. I am supported
>> exclusively by donations, which incidentally, have been steadily
>> *de*creasing since the start of the Asahi Linux project. The project has
>> zero corporate sponsorship.
>>
>> And I do believe the fact that essentially all high-level Linux kernel
>> maintainers and contributors are paid by corporations to do it is a
>> major factor that has caused this community to become wildly out of
>> touch with what it means to be a community FOSS project.
> 
> I'm really not in favor of chiding people for how they earn money, because
> this world isn't fair and critizing people for how they get their bills
> paid is generally not ok. But this is a bit too much to just let it slide.
> 
> It's fairly plausible that you need the social media brigading to generate
> attention that you can convert into enough donations to support the asahi
> project. But someone has to clean up the mess your shitstorms create, it's
> sure not you, which means my and other people's mental health essentially
> pay your bills. And I really do not appreciate that dynamic.
> 

If I were trying to get more funds, I'd be spending my time finding
corporate sponsors, not documenting the failings of the Linux kernel
community in public. Believe it or not, no, the latter doesn't get me
more donations.

Given you have now decided to add "baseless public accusations from a
position of power" to the list of abuses perpetrated by Linux kernel
maintainers, I think it's about time we stop having this conversation.

- Hector

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

[Simona Vetter]

On Fri, Feb 07, 2025 at 02:49:50PM +0100, Simona Vetter wrote:
> When you're that harmful with your calling out, eventually I'm going to be
> fed up, and you get a live round shot across your bow. And if that then
> causes you to ragequit, because you can't actually deal with the heat
> you've been dishing out coming back around the corner:
> 
> Fuck off.

With some sleep, a w/e and slightly less ill temper: As I'd say in Swiss
German, this was suboptimal wording. Or in plain English, a disaster, I
screwed up.

I do not rescind the sentiment I expressed though. I cannot stand people
who punch where they're stronger, and eschew conflict and fold the moment
someone hits back.

> Or as Dave Airlie put it upthread in this conversation:
> 
> "Being toxic on the right side of an argument is still toxic, [...]"

The irony has not entirely escaped me. Oh well.

Remorsefully, Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch