Let me just say that hierarchies are for breaking ties.
The normal process is that Linus prefers we all work through maintainers to cut down on the noise that comes to him. In this case, the maintainer is the reason the noise is coming to Linus. So, it will be up to him to settle it.
Perhaps. That is not my read. I hear Linus saying that he trusts the process and that sticking with it is the solution to working through the problem. He does not say that a maintainer blocking a technically sound patch is a problem. He does not say that he would reject the patch. He does say that the approach taken by Hector ( who is not the one that submitted the patch ) is the wrong one. If Linus had said that the technical approach or the code quality was a problem, I would agree with you. He did not object to either of those things. What he said is that social media is not the solution.
The problem with your timeline is that it completely leaves out the event(s) that Linus is objecting to. I am hoping that is unintentional on your part.
I will know what Linus thinks when he either accepts or rejects the submission from the R4L team.
Really seems like we are agreeing. I get that the limited package set is a feature. I also get that it is both too small and too enterprise to satisfy most people you would describe as a “SO” precisely because they are probably normal people.
You gave the excellent example of Spotify and suggested a Flatpak for that. Honestly, I am not sure where we are in disagreement. Especially since I started by “mostly agreeing” myself. We even agree on that. :)
The release notes refer to the “few remaining issues”.
https://gitlab.gnome.org/GNOME/gimp/-/milestones/3#tab-issues
There seem to be 115 issues on there which is more than “a few”. However, only 3 are listed as blockers. But a dozen of them are crashes.
How many of these need to be fixed before the 3.0 release? Does anybody know?
In the era of Flatpak, I kind of agree with you.
The primary drawback is the complete lack of packages. A home user is going to want something not included and then things fall apart. Flatpaks and Distrobox have made that a lot better.
If you could get away with a RHEL core and Flatpak for apps, you would have a pretty solid setup for a “normal” person.
The project has said it is a goal to move to a dual language model. So, no, it is not reasonable.
What would be reasonable would be technical arguments or pragmatic logistical concerns with the goal of finding solutions. What would be reasonable would be asking for and accepting help.
None of the reasonable stuff is happening. So, it not reasonable.
I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.
All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.
Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.
In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.
If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.
Fair point. I do think burn out is a problem for the process in general. I guess Linux has always benefited from the long line of people looking to contribute. As long as progress is being made, I expect that to continue here.
What code has he not merged? Was his argument technical or political?
I see lots of R4L code being merged in each of the last few releases.
I also do not see the email where Linus supported Christoph. I see the one where he chewed out Hector for “social media brigading”. That is not the same thing as supporting the maintainer. Hector is not even the one submitting the Rust code in question. He just piled on in the LKML later.
Love those two recs
The core packages, including the desktop environment are much more up-to-date than Debian. This addresses one of the core short-comings of Debian while maintaining most of its strengths. LMDE comes with Xapps as well, the core user applications.
It is just a desktop app, not server software.
Unless you mean Distrobox.