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

[Al Viro <viro@zeniv.linux.org.uk>]

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