On Tue, Dec 15, 2020 at 9:14 PM Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS <centos at centos.org> wrote: > Every package that ends up in a RHEL point release is in Stream at some point, right? While I can certainly believe that the cost for the entire CentOS effort is much more than $250K, dropping CentOS point releases just means not gathering the particular versions that ended up in the corresponding RHEL point release. This is exactly what I was talking about. I didn't ask, "how much does it cost to build CentOS". More specifically I was speculating on the amount of additional effort that was specifically required to do CentOS point release support, over and above the standard CentOS development (that RedHat would still be paying for). Having said that- it's possible that RedHat has heavily modified the build path for CentOS, since now it's upstream of RHEL instead of downstream; and if that's the case it could be that the new build path makes it impossible to build point releases. Having said THAT- it should be relatively simple to tag specific versions of packages in CentOS once those packages are released in a RHEL point release, then do an ISO build off of that. (I was guesstimating that it would take one FTE worth of time to do such tagging or other work needed to build the point releases based on the work that had already been done on the Stream updates, that's where I got the $250k from.) It seems as if it ought to actually be less expensive to do things this way than it has traditionally been to do CentOS... since traditionally, the CentOS team has had to pull the SRPMS for RHEL, duplicate a bunch of effort that RedHat had done to build them in the first place, and reconcile differences. Now since CentOS is actually part of the real RHEL build process, the work to create CentOS is paid for by RHEL. Officially. Maybe THAT is the problem. Since CentOS is now part of the official RHEL build pipeline, RedHat is unwilling to allow that work to be used to build the traditional CentOS point releases. They aren't going to directly contribute work that is paid for by RHEL to do the free CentOS releases. In order to do the 'clean room' implementation of point releases they would have to essentially re-duplicate ALL of the work that has traditionally been required to build CentOS... and THAT'S where the requirement of 8 FTE developers and dozens of servers comes from. They would build RHEL point releases and then they would put forth the 8 FTE worth of effort to do a clean-room rebuild of those releases in the form of CentOS, as they always have done. >From an internal view, if I were a RedHat business manager, I could totally see a legitimate desire to not fund a free product with the resources used to build my paid flagship product. Having realized all of the above- and I understand this is pure speculation on my part- from an external view, as a community member, it looks different. It seems like RedHat is saying, "WAAAH WAAAH YOU CAN'T HAVE MY TOYS GIVE THEM BACK OR ELSE!!!!" Even if the above is true regarding internal RHEL management not wanting RHEL funding a free product, *there is NO practical difference* on the effects towards the community. It is still the case that by taking this course of action RedHat has branded itself as being a bad faith actor. It is still the case that it would only cost RedHat a trivial amount- perhaps substantially less than the $250k I estimated- to continue to do CentOS point releases based off of RHEL. It is still the case that RedHat could earn back a huge chunk of the trust that it destroyed, by deciding to spend this trivial amount to continue the status quo of CentOS builds. RedHat needs to keep the following in mind: there is still value in RHEL. Patent indemnification, contractually guaranteed SLA's for defects for mission critical systems, and so forth. This is the whole idea of RedHat's existence, isn't it? To take all of these hundreds of free software packages and repackage them and sell the value that the legal and contractual guarantees offer. As a community we don't want that for CentOS. We know it's "not legally supported". We know that, if it breaks, we get to fix it ourselves or keep all the broken pieces. What we do want is a system that is repeatable, stable, and known. CentOS point releases provide that. CentOS Stream doesn't.