On Tue, Dec 15, 2020 at 9:14 PM Bernstein, Noam CIV USN NRL (6393)
Washington DC (USA) via CentOS <centos@xxxxxxxxxx> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
