[CentOS-devel] Balancing the needs around the CentOS platform

Sat Dec 19 15:20:14 UTC 2020
Jean-Marc Liger <jean-marc.liger at parisdescartes.fr>

Le 19/12/2020 à 10:34, Mark Mielke a écrit :

> On Sat, Dec 19, 2020 at 1:44 AM Karsten Wade <kwade at redhat.com> wrote:
>> I wrote a blog post to share with you:
>> https://blog.centos.org/2020/12/balancing-the-needs-around-the-centos-platform/
>> Below is a fair summary of the blog post, but I encourage you to read
>> the whole thing for the context around the "availability gap" and the
>> "openness gap":
> Hi Karsten:
> It's good to hear your perspective. I understand you are trying to do
> something noble and with value.
> However, these are significant reasons why CentOS Linux is superior to
> CentOS Stream:
> 1. Bug-for-bug compatibility with RHEL. This is important or a variety
> of reasons, particularly including reproducibility. If something works
> in CentOS 8 Stream, but fails in RHEL 8, this, or if it works in RHEL
> 8, but fails in CentOS 8 Stream, this means any testing efforts are
> invalid. In strange cases which happen in real life - code that relies
> on bugs will break if the bug is fixed.
> 2. Minor release milestones to stabilize branches. We have breakage
> with most minor release upgrades, and the stabilization process is an
> important method of isolating users from being affected by this. This
> is why CentOS 8 Stream is being said "for developers", while RHEL 8
> would be "for production". It is being said, because it is a real
> thing. If you truly believed minor release milestones were unnecessary
> for CentOS 8 Stream, then you would also believe that minor release
> milestones were unnecessary for RHEL 8.
> 3. CentOS brand. CentOS was just getting recognized by vendors as
> existing by vendors who have install scripts and runtime scripts that
> literally say things like "if /etc/system-release doesn't contain a
> recognized string, then fail". I get questions like "can we use Ubuntu
> or CentOS?" There is no guarantee that CentOS 8 Stream will be
> recognized by these vendors ever. The term wishful thinking comes to
> mind for me.
> I don't agree with you that CentOS cannot be two things. It's quite
> normal for most projects to have an "upstream" and a "LTS" branch.
> This seems like an after the fact justification for some compromises
> that were made behind closed doors.
> I don't think this decision is in tune with what the CentOS users
> want. CentOS 8 Stream addresses a set of requirements that CentOS did
> not address previously, but it does so by abandoning the very reason
> that CentOS existed in the first place. If you wanted to know for sure
> - you would take a referendum. I think there is a reason why no
> referendum was taken.
> Personally, I think:
> 1. CentOS 8 Stream should have been called RHEL 8 Stream.
> 2. CentOS 8 should have continued to exist until a suitable
> replacement was provided, with input from the community.
> The choice to make the decision without consultation with the
> community, is a pretty major violation of trust. No matter the intent
> - no matter the impossible situation you may have felt was thrust upon
> you, to even act like CentOS belongs to the community would require
> some sort of public discussion on the matter. By choosing to proceed
> without this discussion, the people involved made it clear that the
> opinion of the community does not matter to your decision making
> process.
As I previously said, a fair way of doing things would have been : "Hey 
guys since we Red Hat have bought CentOS, making a downstream release of 
RHEL is just a nonsense, It costs us time and money we can save. So 
let's reverse the process and make RHEL a downstream of CentOS Linux. It 
will now be Fedora ELN - > CentOS Stream - > CentOS Linux - > RHEL."

Red Hat would have kill all the clones by releasing CentOS Linux first, 
the Community would have been happy and not anger to help to get a 
better RHEL in the Stream process, and Red Hat folks could have put all 
the value of their brand and specificities in their final products, 
backed with a strong ecosystem they could have controlled.