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!
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/
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...)
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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/9d1c57410b67b48856...
It's an easy fix, I'll have it proposed momentarily.
On Sat, Dec 4, 2021 at 12:16 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
It's an easy fix, I'll have it proposed momentarily.
Done: https://gitlab.com/redhat/centos-stream/rpms/httpd/-/merge_requests/37
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
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. Clearly the pictorial representation presented of the relationship between Stream and RHEL is not an accurate one.
On Sat, Dec 4, 2021 at 3:21 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
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. Clearly the pictorial representation presented of the relationship between Stream and RHEL is not an accurate one.
So far, I haven't seen any updates released for RHEL 9 beta, but any updates would be released from auto-rebuilds for c9s to the rhel9.0 branch internally, most likely.
I hope there is a refresh soon, because the current media calls itself beta0, which implies beta1 or beta2 composes will exist.
If you think of the development process of CentOS Stream and RHEL like how Fedora packages are developed, it'll probably be easier to understand. That is, c9s is the head branch, and developers would merge that back into rhel9.0 and rhel9.0-pre branches.
On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 3:21 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
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.
There are cases, such as embargoed CVEs, where RHEL gets work first, but drawing diagrams for every possible scenario isn't really helpful.
So far, I haven't seen any updates released for RHEL 9 beta, but any updates would be released from auto-rebuilds for c9s to the rhel9.0 branch internally, most likely.
I hope there is a refresh soon, because the current media calls itself beta0, which implies beta1 or beta2 composes will exist.
RHEL major releases have two different kinds of Betas. There is the public beta, which is accessible via FTP by anyone, and there is a customer Beta program for RHEL customers that have subscriptions. We do not refresh the public Beta.
As a reminder, those interested in any possible updates to RHEL 9 before the GA can sign up for a free Developer subscription and have access to the Beta channels on CDN.
If you think of the development process of CentOS Stream and RHEL like how Fedora packages are developed, it'll probably be easier to understand. That is, c9s is the head branch, and developers would merge that back into rhel9.0 and rhel9.0-pre branches.
This is a good way to think about the general development flow.
josh
On 04/12/2021 23:30, Josh Boyer wrote:
On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 3:21 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
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?
Maybe it's just semantics, or a naming thing, but there are irresolvable inconsistencies between the pictorial representation presented and the SPEC file changelog entries.
On Sun, 5 Dec 2021, 01:26 Phil Perry, pperry@elrepo.org wrote:
On 04/12/2021 23:30, Josh Boyer wrote:
On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 3:21 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
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/
which shows the same concept but from a slightly different angle.
SPEC file changelog entries.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 05/12/2021 01:27, Aleksandra Fedorova wrote:
On Sun, 5 Dec 2021, 01:26 Phil Perry, <pperry@elrepo.org mailto:pperry@elrepo.org> wrote:
On 04/12/2021 23:30, Josh Boyer wrote: > On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa <ngompa13@gmail.com <mailto:ngompa13@gmail.com>> wrote: >> >> On Sat, Dec 4, 2021 at 3:21 PM Phil Perry <pperry@elrepo.org <mailto:pperry@elrepo.org>> wrote: >>> >>> On 04/12/2021 17:16, Neal Gompa wrote: >>>> On Sat, Dec 4, 2021 at 11:58 AM Phil Perry <pperry@elrepo.org <mailto:pperry@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?
On Sun, Dec 5, 2021 at 5:43 AM Phil Perry pperry@elrepo.org wrote:
On 05/12/2021 01:27, Aleksandra Fedorova wrote:
On Sun, 5 Dec 2021, 01:26 Phil Perry, <pperry@elrepo.org mailto:pperry@elrepo.org> wrote:
On 04/12/2021 23:30, Josh Boyer wrote: > On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa <ngompa13@gmail.com <mailto:ngompa13@gmail.com>> wrote: >> >> On Sat, Dec 4, 2021 at 3:21 PM Phil Perry <pperry@elrepo.org <mailto:pperry@elrepo.org>> wrote: >>> >>> On 04/12/2021 17:16, Neal Gompa wrote: >>>> On Sat, Dec 4, 2021 at 11:58 AM Phil Perry <pperry@elrepo.org <mailto:pperry@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.
Hi,
On Sun, Dec 5, 2021 at 11:43 AM Phil Perry pperry@elrepo.org wrote:
On 05/12/2021 01:27, Aleksandra Fedorova wrote:
... (skipped) ...
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?
It a naming issue but it also the fact that RHEL builds of a next minor release exist in parallel to CentOS Stream builds: Every time we do a merge to the CentOS Stream 9 dist-git, we build two packages out of it: the CentOS Stream 9 package and the RHEL 9.Y.0 package, where Y changes every half a year and represents the next minor release which has not yet branched.
RHEL 9 Beta is 9.Y.0 with Y=-1. In Beta development cycle Beta build appeared at the same time as the CentOS Stream build. Both builds passed the joint QE gate and landed in Beta nightly and CentOS Stream nightly respectively at the same time.
Thus from the RHEL developer point of view Beta was not created at branching point as it was developed and built the whole time. Branching only decoupled it from the CentOS Stream to allow the freeze.
And even on the infra side branching of Beta doesn't mean creation of Beta branch. Rather it creates new RHEL 9.0.0 branch, similarly how branching of Fedora 35 creates f36 branch for Fedora Rawhide.
So while we do changes in CentOS Stream dist-git, we do them as a development of a certain next minor release of RHEL.
It probably is going to be less visible in next minor releases though. Once RHEL 9 Beta is released, there won't be any large actions like mass-rebuilds anymore, and development becomes more focused on individual bug fixes, which should have their dedicated changelog entries.
On Sat, Dec 4, 2021 at 7:26 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 23:30, Josh Boyer wrote:
On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 3:21 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
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?
Maybe it's just semantics, or a naming thing, but there are irresolvable inconsistencies between the pictorial representation presented and the SPEC file changelog entries.
The RHEL 9 Beta is largely based on CentOS Stream 9 content at the end of August. You can tell because most packages have the changelog entry for the mass build to add IMA signatures from the beginning of August with a few others ending at mid to late August. There are some packages that were backported from c9s to the beta, and you can tell because they have the DistTag "el9_b", and their changelog entries reach up to the end of September.
People have been fixing things in CentOS Stream 9 based on bugs found in the RHEL 9 Beta, but I agree the feedback loop is pretty bad for the Beta still.
Am 05.12.21 um 01:26 schrieb Phil Perry:
On 04/12/2021 23:30, Josh Boyer wrote:
On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 3:21 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
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?
Maybe it's just semantics, or a naming thing, but there are irresolvable inconsistencies between the pictorial representation presented and the SPEC file changelog entries.
I find this illustration interesting (starting at second 1355)
https://www.youtube.com/watch?v=oktwEpjO38M&t=1355s
-- Leon
On Sat, 4 Dec 2021 at 19:26, Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 23:30, Josh Boyer wrote:
On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 3:21 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@elrepo.org wrote:
On 23/11/2021 12:24, Alex Iribarren wrote:
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.
The part that is missing on the pictorial graph are all the feedback loops which go on. There need to be lines going back from RHEL into Fedora, CentOS Stream, and RHEL itself.. and also vice versa as an engineer looks for a 'fix' and finds it elsewhere or needs to feed back a fix to something 'later'. I pointed this out but had to agree with Carl and Aleksandra that my attempts to cover all the cases to make it more accurate made the chart unreadable. The real flowchart would be a mass of different coloured lines, different directions and a lot of tools which while for someone who loves intricate design flows would love.. just looks like a mass of spaghetti with blueberry and tomato sauce mixed together (and about as appetizing).
On Sat, Dec 4, 2021 at 6:31 PM Josh Boyer jwboyer@redhat.com wrote:
On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 3:21 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
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.
There are cases, such as embargoed CVEs, where RHEL gets work first, but drawing diagrams for every possible scenario isn't really helpful.
So far, I haven't seen any updates released for RHEL 9 beta, but any updates would be released from auto-rebuilds for c9s to the rhel9.0 branch internally, most likely.
I hope there is a refresh soon, because the current media calls itself beta0, which implies beta1 or beta2 composes will exist.
RHEL major releases have two different kinds of Betas. There is the public beta, which is accessible via FTP by anyone, and there is a customer Beta program for RHEL customers that have subscriptions. We do not refresh the public Beta.
As a reminder, those interested in any possible updates to RHEL 9 before the GA can sign up for a free Developer subscription and have access to the Beta channels on CDN.
My information is based on the Red Hat subscription portal, not the FTP. I didn't even know you bothered to release it on the Red Hat FTP.
On Sat, Dec 4, 2021, 8:32 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 6:31 PM Josh Boyer jwboyer@redhat.com wrote:
On Sat, Dec 4, 2021 at 3:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Dec 4, 2021 at 3:21 PM Phil Perry pperry@elrepo.org wrote:
On 04/12/2021 17:16, Neal Gompa wrote:
On Sat, Dec 4, 2021 at 11:58 AM Phil Perry pperry@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/
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:
- 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/9d1c57410b67b48856...
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
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.
There are cases, such as embargoed CVEs, where RHEL gets work first, but drawing diagrams for every possible scenario isn't really helpful.
So far, I haven't seen any updates released for RHEL 9 beta, but any updates would be released from auto-rebuilds for c9s to the rhel9.0 branch internally, most likely.
I hope there is a refresh soon, because the current media calls itself beta0, which implies beta1 or beta2 composes will exist.
RHEL major releases have two different kinds of Betas. There is the public beta, which is accessible via FTP by anyone, and there is a customer Beta program for RHEL customers that have subscriptions. We do not refresh the public Beta.
As a reminder, those interested in any possible updates to RHEL 9 before the GA can sign up for a free Developer subscription and have access to the Beta channels on CDN.
My information is based on the Red Hat subscription portal, not the FTP. I didn't even know you bothered to release it on the Red Hat FTP.
Ack. My assumption is that most on the list aren't using the Customer Beta so I was getting ahead of future questions.
For what it's worth, any 9 Beta updates are much more accessible than previous RHEL major releases. They simply go to the regular beta channels, which was not previously the case.
josh
On Sun, Dec 5, 2021, at 9:25 AM, Josh Boyer wrote:
For what it's worth, any 9 Beta updates are much more accessible than previous RHEL major releases. They simply go to the regular beta channels, which was not previously the case.
Does this mean High Touch Beta is obsolete?
V/r, James Cassell
On Mon, Dec 6, 2021 at 12:36 AM James Cassell fedoraproject@cyberpear.com wrote:
On Sun, Dec 5, 2021, at 9:25 AM, Josh Boyer wrote:
For what it's worth, any 9 Beta updates are much more accessible than previous RHEL major releases. They simply go to the regular beta channels, which was not previously the case.
Does this mean High Touch Beta is obsolete?
No. The High Touch Beta program still exists.
josh
-
Aleksandra Fedorova -
Alex Iribarren -
James Cassell -
Josh Boyer -
Leon Fauster -
Neal Gompa -
Phil Perry -
Stephen John Smoogen