Redhat doesn't ship btrfs because they don't have any engineers working on it and thus can't provide support for it. Anything that ships in RHEL is comes with a strong support guarantee that they just couldn't hold up for btrfs.
The SAS controllers may be a similar thing, maybe they don't have the hardware anymore to regression test against.
The two are not contradictory. Fedora's btrfs functionality can absolutely be exceptional - nothing about that means that Red Hat has engineers working on or able to effectively support it.
Disclaimer: I am an ex-Red Hat employee, though I was nowhere near RHEL.
rather they don't have any customers demanding it. if they had, hiring engineers to support that should not be the problem.
incidentally, i never had a chance to figure out what the big deal was with the centos stream change, because i was already forced to switch to debian because btrfs was removed from the centos kernel.
CentOS being in lock-step with RHEL minus support also included certain certifications that applied to RHEL also applied to CentOS, most importantly if you were in the business of selling to US government or related customer.
It's enterprise in that you pay for it, but their support sucks. We had lots of open tickets they never solved. Total waste of money. Instead of fixing the problems they went back and forth with us asking for more log files until they just closed out the ticket because of lack of activity. It was their lack of activity.
At least Canonical/Ubuntu enterprise support stumbles into a solution and helps out.
It's been a while, but 5 years ago I worked for a company with a Red Hat support contract, and we found them incredibly helpful. Everyone we spoke to had deep Linux knowledge, and their team solved issues and gave us real worldn advice much faster and better than any vendor. I'd be sad if that's no longer true.
I remember thinking why don't they just do a WebEx with us to see what's going on. Nope, never. They just wanted us to ship logs to them and try random crap until they closed the ticket. Total waste of time and money.
Not if they do it right. Lots of companies did that with us, some required it as part of their contract. We'd give them the ability to control or not, and what we were sharing with them. Way more efficient than sending up a tarball full of /var/log. Id argue THAT was a security and liability issue.
Redhats customers run across the world and many legal jurisdictions, which have their own set of complications.
The flip side of the coin that I have seen is that some customers will rely heavily on redhat to do basic admin work that a system admin would/should be doing. Effectively taking a job with legal liability for work provided.
The sosreport Tarball makes an active effort not to gather private information. If you believe it does, please let support know as they are interested in improving this.
Oracle's UEKR4 stopped updating Intel microcode for several months (in the middle of the spectre/meltdown hysteria). After a community forum post, they demanded an open SR so I had the pleasure of explaining all of this again. Even with a support contract, sometimes they are amazingly obtuse.
We dumped support. We are paying enough for the database as it is.
Two shining examples are the removal of older SAS controllers in the kernels of newer versions, and the fate of btrfs.
OpenELA could easily grow in influence to a point where rhel will lose customers if they try it again.
It will be interesting if such decisions push effective control of rhel to OpenELA. It could easily happen.