822
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 20 Jul 2023
822 points (99.9% liked)
Linux
45457 readers
1441 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
I haven't been really keeping up with this RHEL drama, so I'm probably going to regret making this comment. But about this bug merge request in particular, you have to remember that RHEL's main target audience is paying enterprise customers. It's the "E" right there in RHEL. So stability is a high priority for their developers, since if they accidentally introduce a bug to their code, then they'll have a lot of unhappy paying customers.
The next comment that was cropped out of that screenshot basically explains exactly that. While the Red Hat developers probably appreciate the bug fix, the reality is that the bug was listed as non-critical, and the Red Hat teams didn't have the capacity to adequately regression test and QA the merge request. But the patch was successfully merged into Fedora, so it will eventually end up in RHEL through that path, which is exactly what the Fedora path is for.
The blowup about this particulat bug doesn't seem justified to me. Red Hat obviously can't fix and regression test every single bug that's listed in their bug tracker. So why arbitrarily focus on this one medium priority bug? if it were listed as a critical bug, then yes, the blowup would be justified.
In its blog post Red Hat specifically called out downstream distributions for not contributing anything to the development of RHEL and that they should be making fixes to CentOS Stream. Well, this is a fix for CentOS Stream and Red Hat still doesn't care. They just don't want community contributions.
CentOS Stream is the staging ground for RHEL. It isn't a bleeding edge distro that can accept any merge request willy-nilly. For the reason why, reread my original comment about the nature of enterprise support.
Fedora is the distro that is more bleeding edge in the RHEL realm. This merge request was more suited for Fedora, and the fix was successfully applied to Fedora. So, I fail to see any irrational actions from Red Hat here.
Sounds to me like they messed up the communication between them and the devs. If they directed the PR submitter to Fedora, I think there wouldn't be as much fuel to the fire.
Granted, all the chaos surrounding RHEL does make me a little worried for Fedora. Fedora is not a bad distro by any means, and I don't want to have to not recommend it because of the drama.
The only thing Red Hat has power over Fedora is its name and infrastructure. Red Hat can't decide for Fedora. Do they have Red Hat employees working for Fedora? Yes, they do, but the employees decide for Fedora, not for Red Hat. Besides, all the telemetry drama is being sorted out in the most open way possible over on Discourse (Fedora Discussion). It is still a 100% community distribution despite a lot of people saying "it is already decided" "Fedora is doomed" etc.
I stopped recommending it. It is a pity, but there are alternatives
Why would they accept PR at all if they don't have a robust testing process and approvals are dictated by customers needs?
The message as it is now to potential contributors is that their contribution in not welcome, unless its free labor to financially benefit only ibm.
Which is fair, but the message itself is a new PR issue for red hat
They do have a robust testing process, but their main focus at the CentOS Stream stage is more about preparing for the stable RHEL build than it is about adding a ton of new features and bug fixes. Testing takes time so it would be physically impossible for them to test everything if they didn't have a limit on the type of contributions they accept. For bug fixes, their limit is that the bug has to be critical. For bugs lesser than that, the correct place to contribute those fixes is in Fedora.
That has been adequately explained in the merge request at this point, if you click in that link at the top of this thread amd read through it to get the latest info. The Red Hat devs have also made no indication that they're not welcome to contributors. Anyone who's saying that is blowing this merge request issue out of proportion.
I read it, and I read the messages from the devs. The communication issue I am trying to point is also highlighted in the comments: if the decision on merging a PR is uniquely dictated by financial benefits of IBM, ignoring the broader benefits of the community, the message is that red hat is looking for free labor and it is not really interested in anything else. Which is absolutely the case, as we all know, but writing it down after the recent events is another PR issue, as red hat justified controversial decisions on the lack of contributions from downstream.
The Italian dev tried to put it down as "we have to follow our service management processes that are messy, tedious and expensive" but he didn't address the problems in the original message. The contributor himself felt like they asked his contribution just to reject it because of purely financial reasons without any additional details. It is a new PR incident
I don't know what to tell you. This change was more appropriate for Fedora and developers are bad at PR is basically the simplest way to put it.
Not having resources to test it right this second isn't "doesn't care" it's just a lower priority.