Comment by imiric

This is unfortunate, but before pointing fingers, it's worth putting things into perspective.

The linked "thin blue line" message[1] also says this:

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

Which seems very reasonable. Maintainers shouldn't be expected to support a feature indefinitely just because a 3rd party is interested in upstreaming it. In the case of Rust for Linux and the Asahi project specifically, I imagine this would entail a much larger effort than any other contribution. So just based on this alone, the bar for entry for Asahi-related features should be much higher.

Perhaps this is ultimately a failure of leadership as TFA claims, but it would be foolish to blame the Linux maintainers or its development process, and take sides either way. Maybe what Asahi is trying to accomplish just isn't a good fit for mainline Linux, and they would be better served by maintaining a hard fork, or developing their own kernel.

[1]: https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...