On Fri, Dec 18, 2020 at 11:29 AM Johnny Hughes <johnny at centos.org> wrote: > People who certify things, who certified CentOS Linux for things, are > free to evaluate and do that with CentOS Stream as well. This is what makes me think this isn't as bad as people made it out to be. (And yeah, I take full responsibility for being one of those 'people' LOL). For the community, there are two challenges. One is very easy to overcome and the other is an unknown. (Or perhaps it is a known, once we can get everyone to see from the same perspective.) Suppose it is June of 2022 and I have been collecting and archiving all of the various versions of packages that are coming out for CentOS Stream. Then, maybe RHEL 8.7 is finalized and hits the mirrors. I can analyze the versions of packages that landed in RHEL 8.7. Then I can grab those versions from my archive and tag them "8.7". I could configure my repositories appropriately and build some ISO images. Of course, I couldn't call that "CentOS 8.7" because RedHat has prohibited that. But still I could release ISO's of "Enterprise Respin 8.7". That is the easy problem to overcome. But there's still the question of long term support. Suppose it is 2027 and some major bug is found in OpenSSL. For RedHat customers, RedHat will build a package of OpenSSL for RHEL 8.10 that fixes the bug. I would guess that such an OpenSSL package would NOT be the same one that lands in whatever version of RHEL 9 drops in 2027, since the OpenSSL in RHEL 9 will be based on a later version of OpenSSL and have more features. Presumably that RHEL 8 version of OpenSSL would go through the CentOS Streams process. Theoretically I could pick up that version of the package and provide it as an update to "Enterprise Respin 8.10". Except... how could that RHEL8 version of OpenSSL go through the CentOS Streams process? Based on what we've been told, at that time, "CentOS Streams" would really be "Whatever version of RHEL 9 drops in 2027 + 1". Or maybe it's even RHEL 10 by that point. So maybe long term updates won't go through the CentOS Streams process. So the question for the community is how to account for that second issue. --JK