[bombcar]

The standard procedure is to maintain a fork/patchset that does what you want and you maintain it for years proving that you will do the work you committed to.

Once it’s been around long enough, it has a much better chance of being merged to main.

[dralley]

That has already been the case with Asahi Linux - for years. It exists as a series of forked packages.

The thing is, you do still have to present a light at the end of the tunnel. If, after years of time investment and proven commitment, you're still being fed a bunch of non-technical BS excuses and roadblocks, people are going to start getting real upset.

[dwaite]

However, it may only get merged in by being conceptually re-thought and reimplemented, like the Linux USB or KGI projects back in the day.

The general pushback for changes in Linux are against large impactful changes. They want your code to be small fixes they can fully understand, or drivers that can be excluded from the build system if they start to crash or aren't updated to a new API change.

You can't take a years-maintained external codebase and necessarily convert it to an incremental stream of small patches and optional features for upstream maintainers, unless you knew to impose that sort of restriction on yourself as a downstream maintainer.