[CentOS-devel] De-branding in CentOS Stream 9

Sun Dec 5 10:48:21 UTC 2021
Neal Gompa <ngompa13 at gmail.com>

On Sun, Dec 5, 2021 at 5:43 AM Phil Perry <pperry at elrepo.org> wrote:
>
> On 05/12/2021 01:27, Aleksandra Fedorova wrote:
> >
> >
> > On Sun, 5 Dec 2021, 01:26 Phil Perry, <pperry at elrepo.org
> > <mailto:pperry at elrepo.org>> wrote:
> >
> >     On 04/12/2021 23:30, Josh Boyer wrote:
> >      > On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa <ngompa13 at gmail.com
> >     <mailto:ngompa13 at gmail.com>> wrote:
> >      >>
> >      >> On Sat, Dec 4, 2021 at 3:21 PM Phil Perry <pperry at elrepo.org
> >     <mailto:pperry at elrepo.org>> wrote:
> >      >>>
> >      >>> On 04/12/2021 17:16, Neal Gompa wrote:
> >      >>>> On Sat, Dec 4, 2021 at 11:58 AM Phil Perry <pperry at elrepo.org
> >     <mailto:pperry at elrepo.org>> wrote:
> >      >>>>>
> >      >>>>> On 23/11/2021 12:24, Alex Iribarren wrote:
> >      >>>>>> Hi all,
> >      >>>>>>
> >      >>>>>> While trying to run the CentOS functional tests on CS9[*], I
> >     noticed
> >      >>>>>> that several fail because of branding issues. For example,
> >      >>>>>> p_httpd/httpd_centos_brand_server_tokens.sh expects the
> >     server string to
> >      >>>>>> match `Apache.*\ (CentOS)`, when in fact the server line is:
> >      >>>>>>
> >      >>>>>> Server: Apache/2.4.51 (Red Hat Enterprise Linux 9) OpenSSL/3.0.0
> >      >>>>>>
> >      >>>>>> This got me thinking about how de-branding is supposed to
> >     work in CS9. I
> >      >>>>>> would guess the usual process would have to be reversed now,
> >     where Red
> >      >>>>>> Hat would remove the CentOS brand from CS9 packages and add
> >     the Red Hat
> >      >>>>>> brand for the RHEL 9.0 builds, but clearly this isn't
> >     happening yet. I
> >      >>>>>> guess this is an oversight?
> >      >>>>>>
> >      >>>>>> Cheers,
> >      >>>>>> Alex
> >      >>>>>>
> >      >>>>>> [*] I know, I know, but I have to run *something* before you
> >     guys
> >      >>>>>> release your own functional test suite for CS9!
> >      >>>>>
> >      >>>>> In the absence of anyone from the project commenting, I'm
> >     wondering how
> >      >>>>> RHEL branding could have possibly got into a CentOS Stream
> >     release in
> >      >>>>> the first place?
> >      >>>>>
> >      >>>>> The pictorial representation we are given is clear:
> >      >>>>>
> >      >>>>> https://blog.centos.org/2021/12/introducing-centos-stream-9/
> >     <https://blog.centos.org/2021/12/introducing-centos-stream-9/>
> >      >>>>>
> >      >>>>> CentOS Stream is forked from Fedora Rawhide and exists
> >     upstream of any
> >      >>>>> RHEL release so it's hard to envisage how this could possibly
> >     have
> >      >>>>> happened. Surely now it is a case of RH removing CentOS
> >     branding for
> >      >>>>> their RHEL release if Stream is truly the upstream
> >     development of RHEL?
> >      >>>>>
> >      >>>>> Wouldn't it be simpler to just call it RHEL Stream and do
> >     away with the
> >      >>>>> extra layer of obfuscation and confusion, as that's more what
> >     it looks
> >      >>>>> like (if it walks like a duck...)
> >      >>>>
> >      >>>> That would be a significant deviation of Red Hat's own brand
> >     strategy.
> >      >>>> *All* of Red Hat's products have a "project brand" and a "product
> >      >>>> brand".
> >      >>>>
> >      >>>> This has two major advantages:
> >      >>>>
> >      >>>> 1. It enshrines branding as an aspect of differentiation for
> >     the Red
> >      >>>> Hat offering
> >      >>>> 2. It makes it easy for third parties to make their own branded
> >      >>>> product offerings based on the project and strengthen the
> >     ecosystem.
> >      >>>>
> >      >>>> In this particular case with Apache HTTPD, it's happening because
> >      >>>> CentOS Stream uses the "Red Hat Enterprise Linux" BZ support
> >     product,
> >      >>>> and that's how it gets set at build-time.
> >      >>>>
> >      >>>> See here:
> >     https://gitlab.com/redhat/centos-stream/rpms/httpd/-/blob/9d1c57410b67b48856876b6068b36bd3d1aa32d5/httpd.spec#L6
> >     <https://gitlab.com/redhat/centos-stream/rpms/httpd/-/blob/9d1c57410b67b48856876b6068b36bd3d1aa32d5/httpd.spec#L6>
> >      >>>>
> >      >>>> It's an easy fix, I'll have it proposed momentarily.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>
> >      >>> Hi Neal,
> >      >>>
> >      >>> Thanks for the explanation, most helpful. However, again I'm
> >     confused as
> >      >>> the spec file referenced above has two references in the
> >     changelog to
> >      >>> having been rebuilt for RHEL 9 Beta. Again, how can anything
> >     that has
> >      >>> happened downstream in a RHEL 9 Beta end up back in the
> >     upstream Stream
> >      >>> product? The fact the two changelog entries are 2 months apart
> >     suggest
> >      >>> there is little separation between the RHEL 9 Beta and CentOS
> >     Stream 9.
> >      >
> >      > RHEL 9 Beta was built from CentOS Stream 9.  We had a soft opening
> >      > back in April, and RHEL 9 work has been flowing through CentOS Stream
> >      > 9.  It takes a while to create any RHEL release, Beta or
> >     otherwise, so
> >      > having 2 commits months apart reference 9 Beta isn't uncommon.
> >      >
> >      >>> Clearly the pictorial representation presented of the relationship
> >      >>> between Stream and RHEL is not an accurate one.
> >      >
> >      > It is accurate.  Can you help me understand what is confusing?  It
> >      > shows CentOS Stream 9 being a continuously delivered OS, with RHEL
> >      > releases being derived from it.  In this case, work went into
> >     CentOS 9
> >      > Stream and a while later it showed up in 9 Beta.
> >      >
> >
> >     The pictorial representation shows RHEL 9 Beta (or any RHEL release for
> >     that matter) being forks off the continuously delivered CentOS Stream.
> >     There is no feedback loop shown whereby once forked, anything that
> >     happens in RHEL 9 Beta can end up back in Stream, as Stream has
> >     moved on
> >     since then.
> >
> >     As you say, this fork happened back in April. The httpd SPEC file shows
> >     a rebuild for RHEL 9 Beta on April 16th, and again on June 16th. How
> >     can
> >     the rebuild for RHEL 9 Beta on Jun 16th (or at least the changelog
> >     entry) that occurred 2 months _after_ the fork end up back in Stream?
> >     Their paths diverged (at least) 2 months previously, never to meet
> >     again
> >     according to the pictorial representation?
> >
> >
> > The confusion most likely comes from the misunderstanding, what does
> > branching event  represents for a RHEL point release.
> >
> > The branching of a RHEL point release from CentOS Stream happens at the
> > _end_ of the development cycle for that RHEL release, not at the start
> > of it.
> >
> > So development of RHEL 9 Beta started in April in CentOS Stream after
> > RHEL 9 Alpha branch was created. Then for some time development of Beta
> > (including mass rebuilds) happened in the CentOS Stream because they
> > were the same thing, until Beta got ready to be freezed. Then Beta was
> > branched and freezed while CentOS Stream became the RHEL 9.0.0 development.
> >
> > You can check also the diagram in
> >
> > https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/
> > <https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/>
> >
> > which shows the same concept but from a slightly different angle.
> >
>
> OK, so it's more a naming thing with the chagelog entries then. The
> rebuilds were not for RHEL 9 Beta as stated, as that did not exist at
> the time. The rebuilds were simply for CentOS Stream as part of the
> continuous development, which at some point in the future (Aug 2021)
> would be branched off to form the RHEL 9 Beta product. Perhaps under
> this new model the developers need to understand they are now developing
> for CentOS Stream as the upstream product, not RHEL (unless they are
> delivering updates to a RHEL point release branch)? Development happens
> in CentOS Stream, and RHEL is now the downstream rebuild of what is in
> CentOS Stream, right?
>

That is correct. It's a bit tricky for them, because there's basically
an army of engineers that have rarely or never worked this way before.
They're learning as they go along, and to make matters a bit worse,
the workflow for CentOS to RHEL is not exactly as simple as it should
be. For example, RHEL developers have to deal with both the CentOS
Stream Koji instance and the RHEL Brew instance as part of
development, because they need to merge changes back from c9s into
rhel9 and build it in both places.

I suspect that automation will become part of the story to simplify
the process here eventually. Things are a bit goofy as it's all being
worked out as people go along.



-- 
真実はいつも一つ!/ Always, there's only one truth!