Why are you shifting the goal posts? Also, Red Hat has not been a significant contributor to btrfs for a while (they've mostly been working on XFS and lvm/devicemapper) so them dropping it is hardly a surprise -- Red Hat is not the arbiter of what is a good technology, and there are many other parties that work on Linux.
Are you confusing me with someone else? Because I have never claimed that Redhat has been a major contributor behind Btrfs nor have I claimed that Btrfs development is lacking in contributors.
And to me this is just another voice which is septical of the current state of Btrfs. And while Redhat is not the only voice, it is an important voice.
Sorry, I was responding to a comment that said that btrfs didn't have any "man hours" behind it and your response was basically "and even with those man hours Red Hat still decided against it". It didn't feel like a reasonable response in that context.
Red Hat is an important voice, but please remember that supporting something as part of an enterprise distribution requires that you have engineers that work upstream constantly on said project. You can't just passively support something.
A while ago, most of Red Hat's btrfs developers moved to Facebook and clearly they decided that it wasn't worth the money to hire more people to support btrfs on RHEL. If they didn't see customer demand for it, why should they burden their kernel team with supporting something that nobody is asking them for? SUSE supports btrfs (and not just as a technical preview) and they can switch to SLE if they really want btrfs.
Just because something isn't shipping in RHEL doesn't mean that Red Hat decided that btrfs was bad. They likely decided that either their customers are better suited with other options, or they don't think the cost of getting more engineering talent would be worth it. Btrfs is still shipping in Fedora.
