> No, I'm not talking about the people who talk on the phone when you break something. If you find a bug in a package, will Rocky be able to quickly and effectively upstream the fix, or will Rocky end up maintaining you on a custom patchlevel forever?
I'm intrigued. What makes you think Rocky will be faster than Red Hat? How does Rocky handle that situation? Do they have COPR repos or similar that you add to your system? What do they do if the patch gets rejected upstream?
Is your car dealership faster at changing the tires and oil on your car than a tire or oil-changing company would be?
RHEL is effectively a bunch of FOSS bundled and rebranded. Rocky is effectively RHEL with another paint job.
If a patch gets rejected upstream, Red Hat is known to reject the author/maintainer's rationale for this rejection and, over years, may then extend, embrace, and extinguish that community, replacing and repainting it as their product.
Sometimes this is a community-serving change (i.e., docker -> (OCI+) -> podman), and sometimes it's a community-replacing change (i.e., Kubernetes -> Origin/OKD -> Openshift). In all cases, it's a redeclaration of who actually is the most knowledgeable expert. Management re-assigning experts is not necessarily as aligned as the merit of an original engineering team/community providing their solution.
I'd rather Rocky's solution than the walled-garden in a cathedral courtyard approach. If something cannot be pushed upstream (i.e., user-hostile defaults, vendor lock-in, or arbitrary rebranding), this blockage is sometimes a feature we all want for FOSS, even while it may not give privileges to those who can throw more money at the problem under the condition it will then be able to extract more profit.
I'm intrigued. What makes you think Rocky will be faster than Red Hat? How does Rocky handle that situation? Do they have COPR repos or similar that you add to your system? What do they do if the patch gets rejected upstream?