Hi all,
Obviously many will have seen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
and see, where EL (contributors like you of fedora/EPEL) have been knocked down:
https://bugzilla.redhat.com/show_bug.cgi?id=2215299
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
I see an impasse here. Why contribute to fedora when Red Hat will lock it down in other products?
Regards
Phil
I see an impasse here. Why contribute to fedora when Red Hat will lock it
down in other products?
They literally cannot "Lock it down" due to the GPL. Anyone using RHEL binaries has legal right to the code. What they seem to have done is limit source code access to those who are actually using RHEL, which is all the GPL requires. The GPL does not require you to share source code with every person on the planet, only those using your binaries. If someone wants the source, they can sign up for a free DEV license for RHEL, and that entitles them to the source code for the RHEL things they are using.
On Wed, Jun 21, 2023 at 4:07 PM Philip Wyett philip.wyett@kathenas.org wrote:
Hi all,
Obviously many will have seen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
and see, where EL (contributors like you of fedora/EPEL) have been knocked down:
https://bugzilla.redhat.com/show_bug.cgi?id=2215299
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
I see an impasse here. Why contribute to fedora when Red Hat will lock it down in other products?
Regards
Phil
-- *** Playing the game for the games own sake. ***
Associations:
- Debian Maintainer (DM)
- Fedora/EPEL Maintainer.
- Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, 2023-06-21 at 16:10 -0400, JT wrote:
I see an impasse here. Why contribute to fedora when Red Hat will lock it down in other
products?
They literally cannot "Lock it down" due to the GPL. Anyone using RHEL binaries has legal right to the code. What they seem to have done is limit source code access to those who are actually using RHEL, which is all the GPL requires. The GPL does not require you to share source code with every person on the planet, only those using your binaries. If someone wants the source, they can sign up for a free DEV license for RHEL, and that entitles them to the source code for the RHEL things they are using.
The Free dev account was never mentioned in the announcement. Can Red Hat confirm it will stay and those who access srpms, rebuild then for other purposes will not have accounts cancelled?
Regards
Phil
Red Hat doesn't need to mention it. It's a legal requirement of the GPL... anyone using the binaries has legal right to the source code.
As for Red Hat cancelling users accounts who pull the source build binaries and share it... that'd probably land them in a lawsuit, because as long as that person who originally downloaded the code has the binaries... they are legally entitled to the source for them for as long as they have the binaries.
Furthermore, anyone who shares a binary they build from RH sources... has a legal requirement to share the source onto the next person.
These are precisely the type of issues with the MIT/BSD license that Stallman wanted to address with the GPL.
Red Hat could terminate the dev license... and put RHEL entirely behind a paywall, but they have not stated that they are doing so. And I would imagine that they would get a ton of backlash if they did considering that was how they addressed the reaction the CentOS/CentOS Stream change. But even if they did that, they still have to provide source to anyone with the binaries. So all it would take is one person buying a license, and then releasing the code. Even if Red Hat banned that account, there would just be another account to do the same thing again. Red Hat would have to play whack-a-mole to try to stop people from doing that constantly.
On Wed, Jun 21, 2023 at 4:14 PM Philip Wyett philip.wyett@kathenas.org wrote:
On Wed, 2023-06-21 at 16:10 -0400, JT wrote:
I see an impasse here. Why contribute to fedora when Red Hat will lock
it down in other
products?
They literally cannot "Lock it down" due to the GPL. Anyone using RHEL
binaries has legal right
to the code. What they seem to have done is limit source code access to those who are
actually using RHEL,
which is all the GPL requires. The GPL does not require you to share
source code with every
person on the planet, only those using your binaries. If someone wants the source, they can sign up for a free DEV license for
RHEL, and that entitles
them to the source code for the RHEL things they are using.
The Free dev account was never mentioned in the announcement. Can Red Hat confirm it will stay and those who access srpms, rebuild then for other purposes will not have accounts cancelled?
Regards
Phil
-- *** Playing the game for the games own sake. ***
Associations:
- Debian Maintainer (DM)
- Fedora/EPEL Maintainer.
- Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
On Wed, 2023-06-21 at 16:23 -0400, JT wrote:
Red Hat doesn't need to mention it. It's a legal requirement of the GPL... anyone using the binaries has legal right to the source code.
As for Red Hat cancelling users accounts who pull the source build binaries and share it... that'd probably land them in a lawsuit, because as long as that person who originally downloaded the code has the binaries... they are legally entitled to the source for them for as long as they have the binaries.
Furthermore, anyone who shares a binary they build from RH sources... has a legal requirement to share the source onto the next person.
These are precisely the type of issues with the MIT/BSD license that Stallman wanted to address with the GPL.
Red Hat could terminate the dev license... and put RHEL entirely behind a paywall, but they have not stated that they are doing so. And I would imagine that they would get a ton of backlash if they did considering that was how they addressed the reaction the CentOS/CentOS Stream change. But even if they did that, they still have to provide source to anyone with the binaries. So all it would take is one person buying a license, and then releasing the code. Even if Red Hat banned that account, there would just be another account to do the same thing again. Red Hat would have to play whack-a-mole to try to stop people from doing that constantly.
Whack-a-mole is not what we want to play and we are aware of MIT and GPL licenses. What the community needs is a free source of entry. I believe the GPL asks you never have to make agreement to access GPL code. However Red Hat have not defined what a customer and partner is, but this requires having a Red Hat account which requires agreeing to terms etc. to access the srpms.
Regards
Phil
I believe the GPL asks you never have to make agreement to access GPL
code.
Correct. Per the GPL if you have the binary you have a legal right to the code. Also the GPL does contain clauses that stipulate that outside agreements cannot excuse anyone from the conditions of the license, see the No Surrender of Others' Freedom section.
Also keep in mind that you can download the RHEL ISOs for free without a dev license from this page: https://developers.redhat.com/products/rhel/download You can't update the packages, but you can install that version of RHEL on your computer and use it. So anyone grabbing that ISO has legal right to the source code for the base system.
On Wed, Jun 21, 2023 at 4:35 PM Philip Wyett philip.wyett@kathenas.org wrote:
On Wed, 2023-06-21 at 16:23 -0400, JT wrote:
Red Hat doesn't need to mention it. It's a legal requirement of the
GPL... anyone using the
binaries has legal right to the source code.
As for Red Hat cancelling users accounts who pull the source build
binaries and share it...
that'd probably land them in a lawsuit, because as long as that person
who originally downloaded
the code has the binaries... they are legally entitled to the source for
them for as long as they
have the binaries.
Furthermore, anyone who shares a binary they build from RH sources...
has a legal requirement to
share the source onto the next person.
These are precisely the type of issues with the MIT/BSD license that
Stallman wanted to address
with the GPL.
Red Hat could terminate the dev license... and put RHEL entirely behind
a paywall, but they have
not stated that they are doing so. And I would imagine that they would
get a ton of backlash if
they did considering that was how they addressed the reaction the
CentOS/CentOS Stream change.
But even if they did that, they still have to provide source to anyone
with the binaries. So all
it would take is one person buying a license, and then releasing the
code.
Even if Red Hat banned that account, there would just be another account
to do the same thing
again. Red Hat would have to play whack-a-mole to try to stop people
from doing that constantly.
Whack-a-mole is not what we want to play and we are aware of MIT and GPL licenses. What the community needs is a free source of entry. I believe the GPL asks you never have to make agreement to access GPL code. However Red Hat have not defined what a customer and partner is, but this requires having a Red Hat account which requires agreeing to terms etc. to access the srpms.
Regards
Phil
-- *** Playing the game for the games own sake. ***
Associations:
- Debian Maintainer (DM)
- Fedora/EPEL Maintainer.
- Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
On Wed, 2023-06-21 at 16:49 -0400, JT wrote:
I believe the GPL asks you never have to make agreement to access GPL code.
Correct. Per the GPL if you have the binary you have a legal right to the code. Also the GPL does contain clauses that stipulate that outside agreements cannot excuse anyone from the conditions of the license, see the No Surrender of Others' Freedom section.
Also keep in mind that you can download the RHEL ISOs for free without a dev license from this page: https://developers.redhat.com/products/rhel/download You can't update the packages, but you can install that version of RHEL on your computer and use it. So anyone grabbing that ISO has legal right to the source code for the base system.
Who says that developer account will be available soon, Have Red Hat made a commitment to keep it?
People want to update a system and not fart about, updating via ISO or installing a new system every 6 months is a joke.
Regards
Phil
Who says that developer account will be available soon, Have Red Hat
made a commitment to keep it?
People want to update a system and not fart about, updating via ISO or
installing a new system every 6 months is a joke.
You can download ISOs without a dev account. Someone could easily get the SRPMS as they are entitled to have and compile them and make a 3rd party repo that everyone could add and update from, so people wouldn't have to re-install. My point is that Red Hat is not able to lock down the code because of the GPL. There will always be a way around anything they try to put in place.
People in the FLOSS world really care about this stuff and are also really stubborn... if Red Hat tries to do anything like this, there will be thousands of people that will come together to work around everything Red Hat attempts to put in place to block people.
Don't worry, take a deep breath and relax, the code will remain open source and it will remain freely available.
On Wed, Jun 21, 2023 at 4:56 PM Philip Wyett philip.wyett@kathenas.org wrote:
On Wed, 2023-06-21 at 16:49 -0400, JT wrote:
I believe the GPL asks you never have to make agreement to access GPL
code.
Correct. Per the GPL if you have the binary you have a legal right to
the code.
Also the GPL does contain clauses that stipulate that outside agreements
cannot excuse anyone
from the conditions of the license, see the No Surrender of Others'
Freedom section.
Also keep in mind that you can download the RHEL ISOs for free without a
dev license from this
page: https://developers.redhat.com/products/rhel/download You can't
update the packages, but
you can install that version of RHEL on your computer and use it. So
anyone grabbing that ISO
has legal right to the source code for the base system.
Who says that developer account will be available soon, Have Red Hat made a commitment to keep it?
People want to update a system and not fart about, updating via ISO or installing a new system every 6 months is a joke.
Regards
Phil
-- *** Playing the game for the games own sake. ***
Associations:
- Debian Maintainer (DM)
- Fedora/EPEL Maintainer.
- Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
On Wed, 2023-06-21 at 17:07 -0400, JT wrote:
Who says that developer account will be available soon, Have Red Hat made a commitment to keep
it?
People want to update a system and not fart about, updating via ISO or installing a new
system every 6 months is a joke.
You can download ISOs without a dev account. Someone could easily get the SRPMS as they are entitled to have and compile them and make a 3rd party repo that everyone could add and update from, so people wouldn't have to re-install. My point is that Red Hat is not able to lock down the code because of the GPL. There will always be a way around anything they try to put in place.
People in the FLOSS world really care about this stuff and are also really stubborn... if Red Hat tries to do anything like this, there will be thousands of people that will come together to work around everything Red Hat attempts to put in place to block people.
Don't worry, take a deep breath and relax, the code will remain open source and it will remain freely available.
On Wed, Jun 21, 2023 at 4:56 PM Philip Wyett philip.wyett@kathenas.org wrote:
On Wed, 2023-06-21 at 16:49 -0400, JT wrote:
I believe the GPL asks you never have to make agreement to access GPL code.
Correct. Per the GPL if you have the binary you have a legal right to the code. Also the GPL does contain clauses that stipulate that outside agreements cannot excuse anyone from the conditions of the license, see the No Surrender of Others' Freedom section.
Also keep in mind that you can download the RHEL ISOs for free without a dev license from
this
page: https://developers.redhat.com/products/rhel/download You can't update the packages,
but
you can install that version of RHEL on your computer and use it. So anyone grabbing that
ISO
has legal right to the source code for the base system.
Who says that developer account will be available soon, Have Red Hat made a commitment to keep it?
People want to update a system and not fart about, updating via ISO or installing a new system every 6 months is a joke.
Regards
Phil
Hi,
How are you downloading RHEL ISO images?
Please do not tell me to take a deep breath and relax. Show some respect.
Regards
Phil
How are you downloading RHEL ISO images?
I already sent you the URL in a prior response: https://developers.redhat.com/products/rhel/download
Please do not tell me to take a deep breath and relax. Show some respect.
I am being respectful, I've been trying to explain to you that this isn't anything to get stressed out over. I've calmly addressed the questions you've raised. What you are worried about is not possible because of the legal requirements of the GPL which Red Hat has accepted by using GPL licensed code.
You're stressing out over a non issue... you dont need to stress over this... aka... you can relax... it's going to be ok.
If me addressing your concerns and telling you that you dont need to worry is disrespectful... well... I'm sorry that you think I'm being disrespectful. I'm trying to make you feel better by explaining that you dont need to be worried.
On Wed, Jun 21, 2023 at 5:12 PM Philip Wyett philip.wyett@kathenas.org wrote:
On Wed, 2023-06-21 at 17:07 -0400, JT wrote:
Who says that developer account will be available soon, Have Red Hat
made a commitment to keep
it?
People want to update a system and not fart about, updating via ISO or
installing a new
system every 6 months is a joke.
You can download ISOs without a dev account. Someone could easily get
the SRPMS as they are
entitled to have and compile them and make a 3rd party repo that
everyone could add and update
from, so people wouldn't have to re-install. My point is that Red Hat
is not able to lock down
the code because of the GPL. There will always be a way around anything
they try to put in
place.
People in the FLOSS world really care about this stuff and are also
really stubborn... if Red Hat
tries to do anything like this, there will be thousands of people that
will come together to work
around everything Red Hat attempts to put in place to block people.
Don't worry, take a deep breath and relax, the code will remain open
source and it will remain
freely available.
On Wed, Jun 21, 2023 at 4:56 PM Philip Wyett philip.wyett@kathenas.org
wrote:
On Wed, 2023-06-21 at 16:49 -0400, JT wrote:
I believe the GPL asks you never have to make agreement to access
GPL code.
Correct. Per the GPL if you have the binary you have a legal right
to the code.
Also the GPL does contain clauses that stipulate that outside
agreements cannot excuse anyone
from the conditions of the license, see the No Surrender of Others'
Freedom section.
Also keep in mind that you can download the RHEL ISOs for free
without a dev license from
this
page: https://developers.redhat.com/products/rhel/download You
can't update the packages,
but
you can install that version of RHEL on your computer and use it.
So anyone grabbing that
ISO
has legal right to the source code for the base system.
Who says that developer account will be available soon, Have Red Hat
made a commitment to keep
it?
People want to update a system and not fart about, updating via ISO or
installing a new system
every 6 months is a joke.
Regards
Phil
Hi,
How are you downloading RHEL ISO images?
Please do not tell me to take a deep breath and relax. Show some respect.
Regards
Phil
-- *** Playing the game for the games own sake. ***
Associations:
- Debian Maintainer (DM)
- Fedora/EPEL Maintainer.
- Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
On Wed, 2023-06-21 at 16:49 -0400, JT wrote:
I believe the GPL asks you never have to make agreement to access GPL code.
Correct. Per the GPL if you have the binary you have a legal right to the code. Also the GPL does contain clauses that stipulate that outside agreements cannot excuse anyone from the conditions of the license, see the No Surrender of Others' Freedom section.
Also keep in mind that you can download the RHEL ISOs for free without a dev license from this page: https://developers.redhat.com/products/rhel/download You can't update the packages, but you can install that version of RHEL on your computer and use it. So anyone grabbing that ISO has legal right to the source code for the base system.
I maybe wrong but even the ISO images require a Red Hat account. I know they do as I just tried via clean VM.
Regards
Phil
On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:
Hi all,
Obviously many will have seen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
and see, where EL (contributors like you of fedora/EPEL) have been knocked down:
https://bugzilla.redhat.com/show_bug.cgi?id=2215299
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL.
On Wed, 2023-06-21 at 16:26 -0400, Gerald Henriksen wrote:
On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:
Hi all,
Obviously many will have seen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
and see, where EL (contributors like you of fedora/EPEL) have been knocked down:
https://bugzilla.redhat.com/show_bug.cgi?id=2215299
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL.
Hi,
Red Hat cannot do all the work that fedora does and CentOS stream is a staging post currently for the break off that will become RHEL. This may change and fedora becomes a non-entity to be discarded, but only Red Hat can tell us.
Regards
Phil
On Wed, Jun 21, 2023 at 4:07 PM Philip Wyett philip.wyett@kathenas.org wrote:
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
I'm not particularly inclined to feel favorably toward Red Hat, but I don't see what the availability of RHEL srpms has to do with Fedora. We're upstream of RHEL.
On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen ghenriks@gmail.com wrote:
My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL.
Not really. Fedora is the basis for new RHEL major versions (e.g. RHEL 10). CentOS Stream is the next RHEL minor version (9.X).
On Wed, 2023-06-21 at 16:58 -0400, Ben Cotton wrote:
On Wed, Jun 21, 2023 at 4:07 PM Philip Wyett philip.wyett@kathenas.org wrote:
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
I'm not particularly inclined to feel favorably toward Red Hat, but I don't see what the availability of RHEL srpms has to do with Fedora. We're upstream of RHEL.
On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen ghenriks@gmail.com wrote:
My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL.
Not really. Fedora is the basis for new RHEL major versions (e.g. RHEL 10). CentOS Stream is the next RHEL minor version (9.X).
Hi Ben,
It has much to do. Fedora is a community apparently Red Hat no longer needs. The now ELN backend can satisfy pre testing and could make fedora redundant.
Regards
Phil
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
On Wed, Jun 21, 2023 at 5:09 PM Philip Wyett philip.wyett@kathenas.org wrote:
It has much to do. Fedora is a community apparently Red Hat no longer needs. The now ELN backend can satisfy pre testing and could make fedora redundant.
ELN is a build of (some) Fedora packages with EL-specific options, so it requires Fedora.
On Wed, 2023-06-21 at 17:39 -0400, Ben Cotton wrote:
On Wed, Jun 21, 2023 at 5:09 PM Philip Wyett philip.wyett@kathenas.org wrote:
It has much to do. Fedora is a community apparently Red Hat no longer needs. The now ELN backend can satisfy pre testing and could make fedora redundant.
ELN is a build of (some) Fedora packages with EL-specific options, so it requires Fedora.
ELN can exist off an internal non fedora tree. Just depends who is updating the tree.
Regards
Phil
ELN is a build of (some) Fedora packages with EL-specific options, so it requires Fedora.
ELN can exist off an internal non fedora tree. Just depends who is updating the tree.
Sure, but... that's the _opposite_ of the direction things are going. Previously, what happened to make a major RHEL release was:
1. Some Fedora Linux Release -> an internal bootstrap 2. ... a year or so of secret work ... 3. RHEL Beta 4. RHEL Release 5. CentOS Linux rebuild 6. Internal RHEL build process, internal work on minor release 7. RHEL updates appear in publiuc 8. CentOS Linux rebuilds of those.
There's no connection to Fedora beyond the intial fork, and a lot of work done inside Red Hat without any transparency.
Now, CentOS Stream brings that to the surface:
1. Fedora Rawhide continually updated 2. ELN maintained in parallel, as part of Fedora 3. At some point, ELN branched to new CentOS Stream 4. ... a year or so of CentOS Stream development in public ... 5. RHEL Beta forked from that, released 6. Work on RHEL updates visible in CentOS Stream 7. Updates appear in CentOS Stream 8. Updates released to RHEL
Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git history from Fedora, which is a big improvement in preserving all of the incredible, valuable work from Fedora contributors.
All of this is the exact opposite of Red Hat preparing to make some new base for RHEL. Additionally, this model provides a clean path for Red-Hat-opinionated decisions to differ from those we make from Fedora. Take BTRFS as an example. Or, the increase in CPU baseline. Like this:
Fedora Linux: Community Space -----------------------------
* Community engineering decisions * No special code privileges due to your employer * Community-run infrastructure with RH investment, significant resources from Amazon, contributions from other companies * Community quality engineering with RH investment * Community support * No cost
CentOS Stream: Shared Space ---------------------------
* Red Hat Engineering decisions with community input * Pull requests from the community, approval from Red Hat engineers * Red Hat-provided and maintained infrastructure * Red Hat quality engineering with partner and community involvement * Community support * no cost
Red Hat Enterprise Linux: Product Space ---------------------------------------
* Red Hat Engineering decisions with customer input * Red Hat engineers and only RH engineers do the work * Red Hat infrastructure * Red Hat quality engineering (mostly done in Stream, though) * Enterprise support * Subscription, including low- and no-cost options
Previously, we had a whole convoluted thing which people tried to describe in terms of MC Escher paintings. This is far better, and Fedora is in a better place. In the earlier setup, CentOS _was_ sometimes positioned as a competitor (although generally, those of us working in the actual Fedora and CentOS communities didn't have any interest in playing that game.)
On Thu, Jun 22, 2023 at 5:02 AM Matthew Miller mattdm@fedoraproject.org wrote:
ELN is a build of (some) Fedora packages with EL-specific options, so it requires Fedora.
ELN can exist off an internal non fedora tree. Just depends who is updating the tree.
Sure, but... that's the _opposite_ of the direction things are going. Previously, what happened to make a major RHEL release was:
- Some Fedora Linux Release -> an internal bootstrap
- ... a year or so of secret work ...
- RHEL Beta
- RHEL Release
- CentOS Linux rebuild
- Internal RHEL build process, internal work on minor release
- RHEL updates appear in publiuc
- CentOS Linux rebuilds of those.
There's no connection to Fedora beyond the intial fork, and a lot of work done inside Red Hat without any transparency.
Now, CentOS Stream brings that to the surface:
- Fedora Rawhide continually updated
- ELN maintained in parallel, as part of Fedora
- At some point, ELN branched to new CentOS Stream
- ... a year or so of CentOS Stream development in public ...
- RHEL Beta forked from that, released
- Work on RHEL updates visible in CentOS Stream
- Updates appear in CentOS Stream
- Updates released to RHEL
Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git history from Fedora, which is a big improvement in preserving all of the incredible, valuable work from Fedora contributors.
All of this is the exact opposite of Red Hat preparing to make some new base for RHEL. Additionally, this model provides a clean path for Red-Hat-opinionated decisions to differ from those we make from Fedora. Take BTRFS as an example. Or, the increase in CPU baseline. Like this:
Fedora Linux: Community Space
- Community engineering decisions
- No special code privileges due to your employer
- Community-run infrastructure with RH investment, significant resources from Amazon, contributions from other companies
- Community quality engineering with RH investment
- Community support
- No cost
CentOS Stream: Shared Space
- Red Hat Engineering decisions with community input
- Pull requests from the community, approval from Red Hat engineers
- Red Hat-provided and maintained infrastructure
- Red Hat quality engineering with partner and community involvement
- Community support
- no cost
Red Hat Enterprise Linux: Product Space
- Red Hat Engineering decisions with customer input
- Red Hat engineers and only RH engineers do the work
- Red Hat infrastructure
- Red Hat quality engineering (mostly done in Stream, though)
- Enterprise support
- Subscription, including low- and no-cost options
Previously, we had a whole convoluted thing which people tried to describe in terms of MC Escher paintings. This is far better, and Fedora is in a better place. In the earlier setup, CentOS _was_ sometimes positioned as a competitor (although generally, those of us working in the actual Fedora and CentOS communities didn't have any interest in playing that game.)
Agree with Matthew fully here. We've been working rather hard internally to adjust the development process for RHEL to be more collaborative and open than it ever has before.
josh
Josh Boyer wrote:
Agree with Matthew fully here. We've been working rather hard internally to adjust the development process for RHEL to be more collaborative and open than it ever has before.
The *development process* is more open, but the production releases, which is the only thing end users are interested in, are less open!
Kevin Kofler
On Fri, Jun 23, 2023 at 6:09 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Josh Boyer wrote:
Agree with Matthew fully here. We've been working rather hard internally to adjust the development process for RHEL to be more collaborative and open than it ever has before.
The *development process* is more open, but the production releases, which is the only thing end users are interested in, are less open!
Actually, this is not true either. Since December 2020, Red Hat Enterprise Linux has added a number of avenues in which you can freely get it:
1. Individuals (16 entitlements, prod use permitted): https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux
2. Teams (mucho entitlements for companies, no prod): https://developers.redhat.com/articles/2022/05/10/access-rhel-developer-team...
3. OSS projects running their own infra (mucho entitlements, prod use permitted): https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-op...
Is it everything that people need? No. Could they do more here? Absolutely. But their willingness to even do this should be applauded.
I will also point out that CentOS Stream is perfectly suitable for production use, and I would argue it provides a differentiated experience in its own right: because CentOS Stream does not go through certification work that locks on specific package versions, any and all fixes done by Red Hat or community members are released immediately after running through the gates and passing the tests at the gates. That shortens the average TTL for non-critical/non-security improvements from 6 months to a couple of weeks.
Offhand, I know CentOS Stream 9 is available as an option in the following VPS providers:
* DigitalOcean * Linode * Vultr * Hetzner * Afterburst
There are a lot of providers out there, and it's quite likely that even more ones that offer it. These are just the ones I've used or are aware of.
Once upon a time, Neal Gompa ngompa13@gmail.com said:
I will also point out that CentOS Stream is perfectly suitable for production use
Is it? At one point, there were considerable gaps in security updates; RHEL 9.x would get an update while CentOS Stream 9 (as the target for RHEL 9.[x+1]) didn't get a corresponding update for quite a while. If Stream doesn't get security updates in a timely fashion, it is not at all suitable for production use.
On Sat, Jun 24 2023 at 08:53:32 AM -0500, Chris Adams linux@cmadams.net wrote:
Is it? At one point, there were considerable gaps in security updates;
RHEL 9.x would get an update while CentOS Stream 9 (as the target for RHEL 9.[x+1]) didn't get a corresponding update for quite a while. If Stream doesn't get security updates in a timely fashion, it is not at all suitable for production use.
So here is the reality with security updates. The vast majority of security updates are shipped in RHEL 3-9 months after we fix them, because minimizing the quantity of updates is an important goal in RHEL to reduce update churn for customers, so we only want to release quick fixes for issues that pose serious risk. (Most security issues are just not very urgent.) This means you get most security fixes drastically sooner in CentOS Stream than you would in RHEL. However, higher-severity security updates do get fixed in RHEL first. Developers are not permitted to fix higher-severity security issues in CentOS Stream until after the fix is shipped in at least one RHEL update. We're encouraged to do so immediately after the fix ships in RHEL, so there *should* only be a minor delay of, say, one or two business days for the developer to notice the update has shipped. So in general, CentOS Stream *should* generally be ahead of RHEL and ideally only slightly behind for the more serious CVEs.
But in practice, we actually currently have a lot of desynced packages where RHEL is ahead of CentOS Stream for various reasons. I believe most such cases are mistakes that need to be corrected, not intentional delays. E.g. if a particular developer just forgets to fix the CVE in CentOS Stream, currently nobody is checking to catch that and complain and get things fixed. Red Hat needs to catch and fix these issues proactively, but is not currently doing so. Since only Red Hat is able to commit to CentOS Stream, the community is limited to tracking desyncs and complaining when it happens. (That would be really valuable to do IMO.)
Michael
Once upon a time, Michael Catanzaro mcatanzaro@redhat.com said:
So here is the reality with security updates. The vast majority of security updates are shipped in RHEL 3-9 months after we fix them, because minimizing the quantity of updates is an important goal in RHEL to reduce update churn for customers, so we only want to release quick fixes for issues that pose serious risk. (Most security issues are just not very urgent.) This means you get most security fixes drastically sooner in CentOS Stream than you would in RHEL. However, higher-severity security updates do get fixed in RHEL first. Developers are not permitted to fix higher-severity security issues in CentOS Stream until after the fix is shipped in at least one RHEL update. We're encouraged to do so immediately after the fix ships in RHEL, so there *should* only be a minor delay of, say, one or two business days for the developer to notice the update has shipped. So in general, CentOS Stream *should* generally be ahead of RHEL and ideally only slightly behind for the more serious CVEs.
But in practice, we actually currently have a lot of desynced packages where RHEL is ahead of CentOS Stream for various reasons. I believe most such cases are mistakes that need to be corrected, not intentional delays. E.g. if a particular developer just forgets to fix the CVE in CentOS Stream, currently nobody is checking to catch that and complain and get things fixed. Red Hat needs to catch and fix these issues proactively, but is not currently doing so. Since only Red Hat is able to commit to CentOS Stream, the community is limited to tracking desyncs and complaining when it happens. (That would be really valuable to do IMO.)
Seems like some tooling/notifications might could help with that, although that type of work is rarely interesting enough to get resource assignment in the business world (and since all of this is done behind Red Hat's curtain, there's AFAIK no path for community involvement). I guess a non-Hatter could use a dev subscription to compare RHEL content to CentOS Stream content and note differences (and file BZes I guess?).
Is there any chance of having a CentOS Stream repo along the lines of Fedora's updates-testing, so that CVEs at least would have some type of available update in a timely manner? With 7 there's the fasttrack repo, but it doesn't actually seem to be used currently (and IIRC wasn't ever a "testing" type channel).
On Sat, Jun 24 2023 at 10:24:58 AM -0500, Chris Adams linux@cmadams.net wrote:
Is there any chance of having a CentOS Stream repo along the lines of Fedora's updates-testing, so that CVEs at least would have some type of available update in a timely manner? With 7 there's the fasttrack repo, but it doesn't actually seem to be used currently (and IIRC wasn't ever a "testing" type channel).
A new -testing repo might make sense indeed. I believe currently updates are held until after Red Hat QA has tested them, which introduces significant delay (although not any delay relative to RHEL updates). I don't know what the chances of this happening are, though. It works really well for Fedora though, where community members regularly catch bugs that would otherwise have reached stable users, so it's certainly something to consider.
Hi,
On Sat, Jun 24, 2023 at 6:09 PM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Sat, Jun 24 2023 at 10:24:58 AM -0500, Chris Adams linux@cmadams.net wrote:
Is there any chance of having a CentOS Stream repo along the lines of Fedora's updates-testing, so that CVEs at least would have some type of available update in a timely manner? With 7 there's the fasttrack repo, but it doesn't actually seem to be used currently (and IIRC wasn't ever a "testing" type channel).
A new -testing repo might make sense indeed. I believe currently updates are held until after Red Hat QA has tested them, which introduces significant delay (although not any delay relative to RHEL updates). I don't know what the chances of this happening are, though. It works really well for Fedora though, where community members regularly catch bugs that would otherwise have reached stable users, so it's certainly something to consider.
I think we should move this conversation to centos-devel mailing list.
But also there is no point in -testing repo for CentOS Stream.
When you build a package in CentOS Koji it gets into c9s-gate tag [1]. These packages are publicly available and if you'd like to use or test them before their RHEL part passed the internal RHEL QE, you can do that.
https://kojihub.stream.centos.org/koji/taginfo?tagID=2
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Once upon a time, Aleksandra Fedorova alpha@bookwar.info said:
When you build a package in CentOS Koji it gets into c9s-gate tag [1]. These packages are publicly available and if you'd like to use or test them before their RHEL part passed the internal RHEL QE, you can do that.
That's not available as a repo though AFAIK.
On Sat, Jun 24, 2023 at 6:36 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Aleksandra Fedorova alpha@bookwar.info said:
When you build a package in CentOS Koji it gets into c9s-gate tag [1]. These packages are publicly available and if you'd like to use or test
them
before their RHEL part passed the internal RHEL QE, you can do that.
That's not available as a repo though AFAIK.
Afaiu the use case we are discussing looks like: there is a CVE fix which you want to land in CentOS Stream as fast as possible. And that specific fix may be delayed because RHEL QE takes time and has to deal with their own priorities.
So the fix is known, there is BZ for it and the merge request for it is also known and merged. The package is built, it is available in koji, but it sits in -gate tag and is not promoted to the -pending( which means compose, buildroot and mirrors) because it waits on RHEL QE.
In this case you don't need a repo, you need just this specific build to apply it on your environment, isn't it?
It is not that creation of repositories is not possible. I just think that having a repo with all of the content of -gate tag wouldn't help here. Especially since -gate tag contains also builds which failed the gating tests and therefore are not expected to be promoted ever.
-- Chris Adams linux@cmadams.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Once upon a time, Aleksandra Fedorova alpha@bookwar.info said:
In this case you don't need a repo, you need just this specific build to apply it on your environment, isn't it?
If I only had one system to worry about, maybe (although maybe not, if the build introduces a new dependency for example). But if I want to install it on a group of systems, managed with Ansible for example, no, that's not really enough (unless I have my own repo infrastructure).
I do have packages on a RHEL9 system that do not appear in https://kojihub.stream.centos.org/koji/ - so the fix is unknown from an external view
On Sat, Jun 24, 2023 at 3:05 PM Michael Catanzaro mcatanzaro@redhat.com wrote:
But in practice, we actually currently have a lot of desynced packages where RHEL is ahead of CentOS Stream for various reasons. I believe most such cases are mistakes that need to be corrected, not intentional delays. E.g. if a particular developer just forgets to fix the CVE in CentOS Stream, currently nobody is checking to catch that and complain and get things fixed. Red Hat needs to catch and fix these issues proactively, but is not currently doing so. Since only Red Hat is able to commit to CentOS Stream, the community is limited to tracking desyncs and complaining when it happens. (That would be really valuable to do IMO.)
Most of the time, as you say, things work well (at least in my experience).
If one does find a security update that did not get streamed, is there a way for a non-customer[0] to open an appropriate ticket both now, and in the future when RH moves their internal bug tracker to jira[1]?
[0] There are those that have used the clones and streams for some time without having to sign up with RH.
[1] It is not clear to me if one will need a formal support contract in order to open tickets into the future jira instances.
On Sat, Jun 24 2023 at 03:26:46 PM +0000, Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
If one does find a security update that did not get streamed, is there a way for a non-customer[0] to open an appropriate ticket both now, and in the future when RH moves their internal bug tracker to jira[1]?
Yes, you do not have to be a customer to use Bugzilla/Jira to report bugs.
On Jun 24, 2023, at 8:05 AM, Michael Catanzaro mcatanzaro@redhat.com wrote:
On Sat, Jun 24 2023 at 08:53:32 AM -0500, Chris Adams linux@cmadams.net wrote:
Is it? At one point, there were considerable gaps in security updates;
RHEL 9.x would get an update while CentOS Stream 9 (as the target for RHEL 9.[x+1]) didn't get a corresponding update for quite a while. If Stream doesn't get security updates in a timely fashion, it is not at all suitable for production use.
So here is the reality with security updates. The vast majority of security updates are shipped in RHEL 3-9 months after we fix them, because minimizing the quantity of updates is an important goal in RHEL to reduce update churn for customers, so we only want to release quick fixes for issues that pose serious risk. (Most security issues are just not very urgent.) This means you get most security fixes drastically sooner in CentOS Stream than you would in RHEL. However, higher-severity security updates do get fixed in RHEL first. Developers are not permitted to fix higher-severity security issues in CentOS Stream until after the fix is shipped in at least one RHEL update. We're encouraged to do so immediately after the fix ships in RHEL, so there *should* only be a minor delay of, say, one or two business days for the developer to notice the update has shipped. So in general, CentOS Stream *should* generally be ahead of RHEL and ideally only slightly behind for the more serious CVEs.
With this development model, what is the thought for those who may want to / be able to submit pull requests to CentOS Stream with security fixes?
On Sun, Jul 2 2023 at 09:53:30 PM +0000, "Smith, Stewart via devel" devel@lists.fedoraproject.org wrote:
With this development model, what is the thought for those who may want to / be able to submit pull requests to CentOS Stream with security fixes?
It really depends. CentOS Stream does accept merge requests. With respect to security fixes in particular, I would certainly expect Red Hat would accept most merge requests that fix security problems. However, landing any change requires a relatively high amount of effort from a relatively large amount of people compared to Fedora, where packagers are in charge and things are much simpler. So whether or not your merge request will be accepted into CentOS Stream will be a business decision rather than a community decision. Factors that are outside your control will be considered (e.g. "how busy is QA team right now?") So my suggestion is to talk to the developers you see in the package changelog before submitting a merge request. Merge requests will often (hopefully even generally) be welcome, but not always. It's open source, but it's not a true community project like Fedora.
For WebKitGTK specifically, I'm not interested in patching individual CVEs in CentOS Stream: it's generally much easier and safer to just always update to the latest upstream release instead.
Michael
On 6/24/23 11:05, Michael Catanzaro wrote:
On Sat, Jun 24 2023 at 08:53:32 AM -0500, Chris Adams linux@cmadams.net wrote:
Is it? At one point, there were considerable gaps in security updates;
RHEL 9.x would get an update while CentOS Stream 9 (as the target for RHEL 9.[x+1]) didn't get a corresponding update for quite a while. If Stream doesn't get security updates in a timely fashion, it is not at all suitable for production use.
So here is the reality with security updates. The vast majority of security updates are shipped in RHEL 3-9 months after we fix them, because minimizing the quantity of updates is an important goal in RHEL to reduce update churn for customers, so we only want to release quick fixes for issues that pose serious risk. (Most security issues are just not very urgent.) This means you get most security fixes drastically sooner in CentOS Stream than you would in RHEL. However, higher-severity security updates do get fixed in RHEL first. Developers are not permitted to fix higher-severity security issues in CentOS Stream until after the fix is shipped in at least one RHEL update. We're encouraged to do so immediately after the fix ships in RHEL, so there *should* only be a minor delay of, say, one or two business days for the developer to notice the update has shipped. So in general, CentOS Stream *should* generally be ahead of RHEL and ideally only slightly behind for the more serious CVEs.
What about stuff that is too urgent to wait on Red Hat QA? There have been vulnerabilities (such as CVE-2013-0156 and Log4Shell) for which unauthenticated, fully automated, remote code execution exploits have been found very, _very_ quickly. There may well be times when attackers can write and use an exploit faster than Red Hat QA can process an update. For these vulnerabilities waiting on Red Hat QA is not an option.
On Sun, Jul 2 2023 at 06:27:48 PM -0400, Demi Marie Obenour demiobenour@gmail.com wrote:
What about stuff that is too urgent to wait on Red Hat QA? There have been vulnerabilities (such as CVE-2013-0156 and Log4Shell) for which unauthenticated, fully automated, remote code execution exploits have been found very, _very_ quickly. There may well be times when attackers can write and use an exploit faster than Red Hat QA can process an update. For these vulnerabilities waiting on Red Hat QA is not an option.
Dire emergencies like these are extremely rare, but when they do occur, everybody needs to work together to get updates out to all users ASAP. That's true for every distro. Hypothetically speaking, if I were ever unfortunate enough to be responsible for an emergency scenario like that, I'd still want enough basic QA to at least ensure that the update won't eat your disk, but such decisions would surely be handled on a case-by-case basis.
In a more normal situation, updates take a few days to prepare. I really don't think there's any problem with how CVEs are handled in CentOS Stream *except* for the problem I mentioned earlier about maintainers forgetting to push package updates to CentOS Stream by mistake. We need a better process to ensure human error doesn't result in CentOS Stream missing security or non-security updates. (This impacts RHEL too, because future minor releases are built from CentOS Stream, and we don't want fixes to disappear in future releases.)
Michael
Am 03.07.23 um 02:00 schrieb Michael Catanzaro:
On Sun, Jul 2 2023 at 06:27:48 PM -0400, Demi Marie Obenour demiobenour@gmail.com wrote:
What about stuff that is too urgent to wait on Red Hat QA? There have been vulnerabilities (such as CVE-2013-0156 and Log4Shell) for which unauthenticated, fully automated, remote code execution exploits have been found very, _very_ quickly. There may well be times when attackers can write and use an exploit faster than Red Hat QA can process an update. For these vulnerabilities waiting on Red Hat QA is not an option.
Dire emergencies like these are extremely rare, but when they do occur, everybody needs to work together to get updates out to all users ASAP. That's true for every distro. Hypothetically speaking, if I were ever unfortunate enough to be responsible for an emergency scenario like that, I'd still want enough basic QA to at least ensure that the update won't eat your disk, but such decisions would surely be handled on a case-by-case basis.
In a more normal situation, updates take a few days to prepare. I really don't think there's any problem with how CVEs are handled in CentOS Stream *except* for the problem I mentioned earlier about maintainers forgetting to push package updates to CentOS Stream by mistake. We need a better process to ensure human error doesn't result in CentOS Stream missing security or non-security updates. (This impacts RHEL too, because future minor releases are built from CentOS Stream, and we don't want fixes to disappear in future releases.)
There is also demand between major release, some "features" are missing in EL9 for instance.
On 2023-06-24 06:53, Chris Adams wrote:
Once upon a time, Neal Gompangompa13@gmail.com said:
I will also point out that CentOS Stream is perfectly suitable for production use
Is it? At one point, there were considerable gaps in security updates;
CentOS delayed security updates for 6-8 weeks, twice a year, every year of its entire existence, and people are still clamoring for it.
Stream's delays seem trivial in comparison. I'm not saying that delays are acceptable, just that this *apparently* isn't a major barrier for self-supported use cases.
I will also point out that CentOS Stream is perfectly suitable for production use, and I would argue it provides a differentiated
Nope, its not perfect for production use. Just an example of _many_:
https://bugzilla.redhat.com/show_bug.cgi?id=2184640
Despite the fact that some critical fixes only land into the compose many weeks later, if at all. Some are only in RHEL while CentOS Stream have a rebased version without the fix. Nope, its not perfect for prod use. Emphasizing perfect here. Everything else is corporate speak. Its just perfect to make contributions, and this is the main intention of "CentOS Stream".
Hi Leon,
On 24. Jun 2023, at 19:44, Leon Fauster via devel devel@lists.fedoraproject.org wrote:
I will also point out that CentOS Stream is perfectly suitable for production use, and I would argue it provides a differentiated
Nope, its not perfect for production use. Just an example of _many_:
Apologies for this particular one. We thought we had everything covered in this area, but we messed up and our tests didn’t catch this before it exploded into our faces. Rest assured it wasn’t because we were trying to use the community as guinea pigs; we ourselves were surprised by the fallout, and have been working internally with the maintainers of our signing keys to get this resolved. That work is still ongoing, but we will probably delay disabling SHA-1 in PGP use until CentOS Stream 10/RHEL 10.
Neal Gompa wrote:
On Fri, Jun 23, 2023 at 6:09 PM Kevin Kofler via devel wrote:
Josh Boyer wrote:
Agree with Matthew fully here. We've been working rather hard internally to adjust the development process for RHEL to be more collaborative and open than it ever has before.
The *development process* is more open, but the production releases, which is the only thing end users are interested in, are less open!
Actually, this is not true either. Since December 2020, Red Hat Enterprise Linux has added a number of avenues in which you can freely get it:
- Individuals (16 entitlements, prod use permitted):
https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux
- Teams (mucho entitlements for companies, no prod):
https://developers.redhat.com/articles/2022/05/10/access-rhel-developer-team...
- OSS projects running their own infra (mucho entitlements, prod use
permitted): https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-op...
That is not "open", it is just free as in beer, for a restricted subset of people. If you are not (explicitly! Not just "try and hope we do not terminate your subscription at our whim") entitled to share the SRPMs, it is NOT open.
I will also point out that CentOS Stream is perfectly suitable for production use
If it were, Red Hat would offer it as a supported alternative to their commercial subscription users. They do not, obviously for a reason. A beta branch is not a production release.
Kevin Kofler
On Sunday, 25 June 2023 at 02:44, Kevin Kofler via devel wrote:
Neal Gompa wrote:
On Fri, Jun 23, 2023 at 6:09 PM Kevin Kofler via devel wrote:
Josh Boyer wrote:
Agree with Matthew fully here. We've been working rather hard internally to adjust the development process for RHEL to be more collaborative and open than it ever has before.
The *development process* is more open, but the production releases, which is the only thing end users are interested in, are less open!
Actually, this is not true either. Since December 2020, Red Hat Enterprise Linux has added a number of avenues in which you can freely get it:
- Individuals (16 entitlements, prod use permitted):
https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux
- Teams (mucho entitlements for companies, no prod):
https://developers.redhat.com/articles/2022/05/10/access-rhel-developer-team...
- OSS projects running their own infra (mucho entitlements, prod
use permitted): https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-op...
That is not "open", it is just free as in beer, for a restricted subset of people. If you are not (explicitly! Not just "try and hope we do not terminate your subscription at our whim") entitled to share the SRPMs, it is NOT open.
The FOSS licenses give you the right to share the SRPMS, sans the Red Hat trademarks. Red Hat's terms of use for their subscriptions state explicitly (in several places), that: [...] This Agreement establishes the rights and obligations associated with Red Hat Products and is not intended to limit your rights to software code under the terms of an open source license. [...]
So, unless you have some specific and verifiable examples, please stop spreading FUD.
Regards, Dominik
On 2023-06-25 14:29, Dominik 'Rathann' Mierzejewski wrote:
The FOSS licenses give you the right to share the SRPMS, sans the Red Hat trademarks.
The GPL, specifically, might guarantee that right, but not all of the distribution is under the terms of the GPL. I don't have a license count for RHEL components, but Fedora looks like it's made up of about 30% GPL components, with the majority being MIT, BSD, or Apache license, none of which prohibit Red Hat from imposing restrictions on their redistribution.
Neal Gompa wrote:
I will also point out that CentOS Stream is perfectly suitable for production use, and I would argue it provides a differentiated experience in its own right: because CentOS Stream does not go through certification work that locks on specific package versions, any and all fixes done by Red Hat or community members are released immediately after running through the gates and passing the tests at the gates. That shortens the average TTL for non-critical/non-security improvements from 6 months to a couple of weeks.
Well, another aspect that I think was not mentioned so far in this discussion is that CentOS Stream has only half the support time of RHEL, which makes it much less useful for production servers (and less advantageous over competitors' offerings such as Ubuntu LTS, which offer a similar support period as CentOS Stream).
This also means that if RH is telling rebuilds to do their own backports from CentOS Stream, that is only going to help them in the first half of the lifecycle. In the second half, there are no point releases, hence also no CentOS Stream that would prepare those. So, as I understand it, the security fixes are then only going to be published through the subscription channels.
Offhand, I know CentOS Stream 9 is available as an option in the following VPS providers:
- DigitalOcean
- Linode
- Vultr
- Hetzner
- Afterburst
At least Hetzner also offers Rocky Linux and (recently added due to customer demand) AlmaLinux. If their customers were happy with CentOS Stream, they would not do that. (For the record, I happen to be one of those customers, for a small VPS (currently still running CentOS 7) and 2 domain names. That is the only involvement I have with Hetzner.)
Kevin Kofler
On Thu, Jun 22, 2023, at 11:01 AM, Matthew Miller wrote:
- Fedora Rawhide continually updated
- ELN maintained in parallel, as part of Fedora
- At some point, ELN branched to new CentOS Stream
- ... a year or so of CentOS Stream development in public ...
- RHEL Beta forked from that, released
- Work on RHEL updates visible in CentOS Stream
- Updates appear in CentOS Stream
- Updates released to RHEL
Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git history from Fedora, which is a big improvement in preserving all of the incredible, valuable work from Fedora contributors.
All of this is the exact opposite of Red Hat preparing to make some new base for RHEL. Additionally, this model provides a clean path for Red-Hat-opinionated decisions to differ from those we make from Fedora. Take BTRFS as an example. Or, the increase in CPU baseline. Like this:
Matthew, this is a great summary and also the understanding I currently have. It might be a good thing if this information lives in a more permanent place that I can refer people to. Perhaps something on Fedora's documentation about the Enterprise Linux ecosystem or a blogpost on either the Fedora or RedHat blogs?
Regards,
Simon
Matthew,
Thanks for sending this out. There is a lot of FUD right now and this plan is what I had hoped was going on. The FPO/RH/IBM should do some additional community engagement to clear this up. A very clear diagram of the development/packaging flow would go a long way and give the community a simple artifact to share in place of all of the FUD.
I was worried after reading some of the misinformation/misunderstanding. I was getting concerned we'd have to start up FUDCons again and fork the project. Thankfully, that does not at all seem to be the case.
Cheers,
On Fri, Jun 23, 2023 at 12:47 AM Simon de Vlieger cmdr@supakeen.com wrote:
On Thu, Jun 22, 2023, at 11:01 AM, Matthew Miller wrote:
- Fedora Rawhide continually updated
- ELN maintained in parallel, as part of Fedora
- At some point, ELN branched to new CentOS Stream
- ... a year or so of CentOS Stream development in public ...
- RHEL Beta forked from that, released
- Work on RHEL updates visible in CentOS Stream
- Updates appear in CentOS Stream
- Updates released to RHEL
Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git history from Fedora, which is a big improvement in preserving all of the incredible, valuable work from Fedora contributors.
All of this is the exact opposite of Red Hat preparing to make some new
base
for RHEL. Additionally, this model provides a clean path for Red-Hat-opinionated decisions to differ from those we make from Fedora.
Take
BTRFS as an example. Or, the increase in CPU baseline. Like this:
Matthew, this is a great summary and also the understanding I currently have. It might be a good thing if this information lives in a more permanent place that I can refer people to. Perhaps something on Fedora's documentation about the Enterprise Linux ecosystem or a blogpost on either the Fedora or RedHat blogs?
Regards,
Simon _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Jun 22, 2023, at 2:01 AM, Matthew Miller mattdm@fedoraproject.org wrote:
ELN is a build of (some) Fedora packages with EL-specific options, so it requires Fedora.
ELN can exist off an internal non fedora tree. Just depends who is updating the tree.
Sure, but... that's the _opposite_ of the direction things are going. Previously, what happened to make a major RHEL release was:
- Some Fedora Linux Release -> an internal bootstrap
- ... a year or so of secret work ...
- RHEL Beta
- RHEL Release
- CentOS Linux rebuild
- Internal RHEL build process, internal work on minor release
- RHEL updates appear in publiuc
- CentOS Linux rebuilds of those.
There's no connection to Fedora beyond the intial fork, and a lot of work done inside Red Hat without any transparency.
This was one of our key reasons to look at Fedora as an explicit upstream for the next generation of Amazon Linux. Without a feedback loop for contributions and changes, it severely limits what you may even want to incorporate, as merging this all for the next major release could be a major pain.
Even trivially small things (such as bug fixes) that are beneficial to all (a random semi-recent example is making `lshw` not do a DNS lookup) weren’t *really* possible to quickly throw a pull request up for before CentOS Streams.
There were other really nice properties of Fedora as well, such as each release having a mass-rebuild and thus you can be fairly sure that at any branch point, everything is quite likely to all build together.
Now, CentOS Stream brings that to the surface:
- Fedora Rawhide continually updated
- ELN maintained in parallel, as part of Fedora
- At some point, ELN branched to new CentOS Stream
- ... a year or so of CentOS Stream development in public ...
- RHEL Beta forked from that, released
- Work on RHEL updates visible in CentOS Stream
- Updates appear in CentOS Stream
- Updates released to RHEL
Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git history from Fedora, which is a big improvement in preserving all of the incredible, valuable work from Fedora contributors.
Maintaining git history is certainly fantastic from a transparency point of view.
Beyond just git trees, we have had a few discussions in the Amazon Linux space on what we do with changelogs in the RPMs as well, especially with the increasing move to rpm-autospec, which means that git-merge of our own trees/rebuilds ends up with the old trick of “Release matches upstream, so it’s easy for humans” no longer that useful.
There’s some balance of: - respect and refer to the amazing work done in the Fedora community - Don’t give Amazon Linux users the false impression that $random_fedora_contributor is who made the change in Amazon Linux that broke their $thing - that’s not fun for anybody. - Be clear as to the changes occurring in an Amazon Linux package update
right now, for AL2023, We have an rpm-autospec-like thing at build time that will merge an `amzn-changelog` file that’s present in the git repo with the ‘%changelog’ in the SPEC file on SRPM build. The aim here is to be able to add changelog entries that are amzn specific easily, while not creating merge conflicts all the time
It’d be great if we ended up with CentOS Stream and Amazon Linux doing the same thing, if only for consistency and being able to set some good expectation / good practice for distros downstream from Fedora.
Maybe it’s a question for Fedora developers: how do you *want* downstream distributions to behave in this area?
There’s guidelines for https://fedoraproject.org/wiki/Remix and https://fedoraproject.org/wiki/Spins_SIG along with https://fedoraproject.org/wiki/Releases/FeatureGenericLogos making some parts of downstream distros easier to do.
All of this is the exact opposite of Red Hat preparing to make some new base for RHEL. Additionally, this model provides a clean path for Red-Hat-opinionated decisions to differ from those we make from Fedora. Take BTRFS as an example. Or, the increase in CPU baseline. Like this:
This reminds me of the item on my TODO list of to start a discussion around how we can better have distro and package level option switches that both Fedora and downstream distros can flip on and off over time. I’ll go do that now...
Fedora Linux: Community Space
- Community engineering decisions
- No special code privileges due to your employer
- Community-run infrastructure with RH investment, significant resources
from Amazon, contributions from other companies
- Community quality engineering with RH investment
- Community support
- No cost
CentOS Stream: Shared Space
- Red Hat Engineering decisions with community input
- Pull requests from the community, approval from Red Hat engineers
- Red Hat-provided and maintained infrastructure
- Red Hat quality engineering with partner and community involvement
- Community support
- no cost
It’s also a good place to collaborate on some of the common base components of a Fedora based distro that has a longer support life cycle than a Fedora release gets. This may be a more significant part of the Amazon Linux story as AL2023 and beyond ages, as well as we tune how we interact with upstreams with bug fixes in an existing OS version.
Red Hat Enterprise Linux: Product Space
- Red Hat Engineering decisions with customer input
- Red Hat engineers and only RH engineers do the work
- Red Hat infrastructure
- Red Hat quality engineering (mostly done in Stream, though)
- Enterprise support
- Subscription, including low- and no-cost options
Previously, we had a whole convoluted thing which people tried to describe in terms of MC Escher paintings. This is far better, and Fedora is in a better place. In the earlier setup, CentOS _was_ sometimes positioned as a competitor (although generally, those of us working in the actual Fedora and CentOS communities didn't have any interest in playing that game.)
If I was going to put a diagram of where Amazon Linux sits in that ecosystem, it’d likely look something like this:
Fedora ——> Amazon Linux ____> CentOS Stream —> RHEL
Oracle has (finally – the community projects Rocky and Alma were much quicker to react) made an announcement about the situation: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-...
Kevin Kofler
On Tue, Jul 11, 2023 at 12:49:10PM +0200, Kevin Kofler via devel wrote:
Oracle has (finally – the community projects Rocky and Alma were much quicker to react) made an announcement about the situation: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-...
SUSE too, but it is not so funny as Oracle's https://www.suse.com/news/SUSE-Preserves-Choice-in-Enterprise-Linux/
Den tis 11 juli 2023 kl 12:49 skrev Kevin Kofler via devel < devel@lists.fedoraproject.org>:
Oracle has (finally – the community projects Rocky and Alma were much quicker to react) made an announcement about the situation:
https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-...
Kevin Kofler
I wonder what they would build Oracle Linux on if RH stop making RHEL?
"Finally, to IBM, here’s a big idea for you. You say that you don’t want to pay all those RHEL developers? Here’s how you can save money: just pull from us. Become a downstream distributor of Oracle Linux. We will happily take on the burden."
/Andreas
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Kevin Kofler via devel venit, vidit, dixit 2023-07-11 12:49:10:
Oracle has (finally – the community projects Rocky and Alma were much quicker to react) made an announcement about the situation: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-...
Thanks for the pointer.
They really make sure that they come out as "the last standing good ones" from this. Cleverly written. And they do have valid points.
It's kind of sad when you know where RedHat and Oracle are coming from, and how predictable that PR twist ist.
Now, if Orcale really makes sure to pick from CentOS Stream as closely (to RHEL) as possible we can take gusses how long it will take Alma and Rocky to change upstreams, or become obsolete.
Michael
Since RHEL is made out from Centos Stream and Centos Stream is made out from Fedora ELN, can't Alma and Rocky branch directly from Fedora? Can we collaborate in some way with those communities so that we support each other? I mean, like we have Fedora ELN and EPEL...
Inviato da Proton Mail mobile
-------- Messaggio originale -------- Il 11 Lug 2023, 12:49, Kevin Kofler via devel ha scritto:
Oracle has (finally – the community projects Rocky and Alma were much quicker to react) made an announcement about the situation: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-... Kevin Kofler _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Den tis 11 juli 2023 kl 19:12 skrev Mattia Verga via devel < devel@lists.fedoraproject.org>:
Since RHEL is made out from Centos Stream and Centos Stream is made out from Fedora ELN, can't Alma and Rocky branch directly from Fedora?
Can we collaborate in some way with those communities so that we support
each other? I mean, like we have Fedora ELN and EPEL...
Wouldn't it make more sense to branch out from CentOS Stream if they want to be close to RHEL?
/Andreas
Inviato da Proton Mail mobile
-------- Messaggio originale -------- Il 11 Lug 2023, 12:49, Kevin Kofler via devel < devel@lists.fedoraproject.org> ha scritto:
Oracle has (finally – the community projects Rocky and Alma were much quicker to react) made an announcement about the situation: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-... Kevin Kofler _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Once upon a time, Mattia Verga mattia.verga@proton.me said:
Since RHEL is made out from Centos Stream and Centos Stream is made out from Fedora ELN, can't Alma and Rocky branch directly from Fedora? Can we collaborate in some way with those communities so that we support each other? I mean, like we have Fedora ELN and EPEL...
Their goal is to replicate, as near as practical, the versions, bug fixes, patches, etc. in RHEL, so that the usage (and for some people, running of pre-compiled binaries) is functionally identical to a given RHEL release. Since Red Hat has long used the "patch rather than upgrade" approach for most packages during a release's lifetime, the only way to get a practically-identical system is to get those same patches.
In theory, any patch to a package in say RHEL 9.2 should eventually land in CentOS Stream 9, because RHEL 9.3 should be forked from CentOS Stream 9, but that doesn't always happen in a convenient time frame (plus sometimes something may be fixed one way in a 9.2 update but differently in 9.3). Also, CentOS Stream 9 will stop getting updated much sooner than RHEL 9.x - when RHEL 9.x transitions to "maintenance mode" (no new functionality planned, just bug/security fixes), CentOS Stream 9 will stop altogether.
And Fedora ELN is aimed at CentOS Stream 10, which will eventually be used to make RHEL 10.0, so is not useful for replicating RHEL 9.x updates.
Am 11.07.23 um 21:02 schrieb Chris Adams:
Once upon a time, Mattia Verga mattia.verga@proton.me said:
Since RHEL is made out from Centos Stream and Centos Stream is made out from Fedora ELN, can't Alma and Rocky branch directly from Fedora? Can we collaborate in some way with those communities so that we support each other? I mean, like we have Fedora ELN and EPEL...
Their goal is to replicate, as near as practical, the versions, bug fixes, patches, etc. in RHEL, so that the usage (and for some people, running of pre-compiled binaries) is functionally identical to a given RHEL release. Since Red Hat has long used the "patch rather than upgrade" approach for most packages during a release's lifetime, the only way to get a practically-identical system is to get those same patches.
In theory, any patch to a package in say RHEL 9.2 should eventually land in CentOS Stream 9, because RHEL 9.3 should be forked from CentOS Stream 9, but that doesn't always happen in a convenient time frame (plus sometimes something may be fixed one way in a 9.2 update but differently in 9.3). Also, CentOS Stream 9 will stop getting updated much sooner than RHEL 9.x - when RHEL 9.x transitions to "maintenance mode" (no new functionality planned, just bug/security fixes), CentOS Stream 9 will stop altogether.
And Fedora ELN is aimed at CentOS Stream 10, which will eventually be used to make RHEL 10.0, so is not useful for replicating RHEL 9.x updates.
An addendum to this:
C8S ends 2024, while RHEL8 ends 2029 C9S ends 2027, while RHEL9 ends 2032
On Tue, Jul 11 2023 at 09:18:57 PM +0200, Leon Fauster via devel devel@lists.fedoraproject.org wrote:
C8S ends 2024, while RHEL8 ends 2029 C9S ends 2027, while RHEL9 ends 2032
You're forgetting the Extended life cycle support phase. RHEL 8 and 9 will both have a 13-year lifecycle (down from 14 years). See this table:
https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates
Michael
SUSE has also jumped in to say they will provide an alternative, but compatible Linux to RH.
Leslie Satenstein
On Tuesday, July 11, 2023 at 06:49:38 a.m. GMT-4, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Oracle has (finally – the community projects Rocky and Alma were much quicker to react) made an announcement about the situation: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-...
Kevin Kofler _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
This is actually good news, especially for the CentOS Stream project.
https://almalinux.org/blog/future-of-almalinux/
Quotes: .... After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible* .... We will also start asking anyone who reports bugs in AlmaLinux OS to attempt to test and replicate the problem in CentOS Stream as well, so we can focus our energy on correcting it in the right place. .... While all of these changes open up a lot of opportunities, we want to be clear about the fact that we are still dedicated to being good open source citizens. We’ll continue to contribute upstream in Fedora and CentOS Stream and to the greater Enterprise Linux ecosystem, just as we have been doing since our inception, and we invite our community to do the same!
On 7/12/23 15:28, Leslie Satenstein via devel wrote:
SUSE has also jumped in to say they will provide an alternative, but compatible Linux to RH.
Leslie Satenstein
On Tuesday, July 11, 2023 at 06:49:38 a.m. GMT-4, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Oracle has (finally – the community projects Rocky and Alma were much quicker to react) made an announcement about the situation: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-... https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/
Kevin Kofler _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org mailto:devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue https://pagure.io/fedora-infrastructure/new_issue
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 14/07/2023 08:16, Carlos Rodriguez-Fernandez wrote:
After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible*
Imagine Red Hat shutting down CentOS Stream in a year or two just because they [Alma, etc.] started doing rebuilds. :-D
On 7/14/23 00:02, Vitaly Zaitsev via devel wrote:
On 14/07/2023 08:16, Carlos Rodriguez-Fernandez wrote:
After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible*
Imagine Red Hat shutting down CentOS Stream in a year or two just because they [Alma, etc.] started doing rebuilds. :-D
That would be epic, LOL.
Carlos Rodriguez-Fernandez wrote:
After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible*
So this is now a significant difference between AlmaLinux and Rocky Linux, which were previously basically two of the same.
Rocky Linux is intent on keeping 1:1 compatibility by obtaining RHEL sources through undocumented (by RH), but apparently legal (at least according to Rocky), tricks:
https://rockylinux.org/news/keeping-open-source-open/
and has reaffirmed this in their forums in light of the AlmaLinux announcement:
https://forums.rockylinux.org/t/has-red-hat-just-killed-rocky-linux/10378/19...
Kevin Kofler
On Wed, Jun 21, 2023 at 5:46 PM Philip Wyett philip.wyett@kathenas.org wrote:
On Wed, 2023-06-21 at 17:39 -0400, Ben Cotton wrote:
On Wed, Jun 21, 2023 at 5:09 PM Philip Wyett philip.wyett@kathenas.org wrote:
It has much to do. Fedora is a community apparently Red Hat no longer needs. The now ELN backend can satisfy pre testing and could make fedora redundant.
ELN is a build of (some) Fedora packages with EL-specific options, so it requires Fedora.
ELN can exist off an internal non fedora tree. Just depends who is updating the tree.
Literally anything CAN happen. However Fedora ELN without Fedora Rawhide would be just CentOS Stream and therefore redundant. The fact that Fedora ELN continues to see significant support from Red Hat (they essentially pay several people to work on it full-time) should make it clear that it has value.
On 2023-06-21 13:26, Gerald Henriksen wrote:
My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL.
I think that's ... kind of true, in a good way.
I don't know if you were around at the time, but before Red Hat Linux split in to RHEL and Fedora, users had long wanted the ability to contribute to the distribution. The split created a community distribution that developers could join, and that distribution became a much larger, high quality distribution.
CentOS Stream is a stable LTS, very similar to other widely used stable LTS releases. Developers can open pull requests for appropriate changes. Red Hat accepts bug reports related to the product.
All of this is a huge improvement over the old CentOS process.
On Wed, Jun 21, 2023 at 04:26:35PM -0400, Gerald Henriksen wrote:
On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:
Hi all,
Obviously many will have seen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
and see, where EL (contributors like you of fedora/EPEL) have been knocked down:
https://bugzilla.redhat.com/show_bug.cgi?id=2215299
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL.
IMHO this is a mis-reading of the above blog / general situation. The flow of development for future versions of RHEL is absolutely still originating in Fedora, where Rawhide feeds into ELN (Enterprise Linux Next), which then becomes the next major RHEL release.
Fedora -> ELN -> RHEL-$NEXT
Nothing described in that blog post above changes this process, so what's written there doesn't have any direct impact on Fedora. If you look at rawhide / eln branches in Fedora dist-git today you can see ongoing changes in many packages that will feed into RHEL-10. CentOS Stream is *not* the new Fedora. Fedora remains critical to future RHEL.
CentOS Stream is the development path *within* a major RHEL release eg
CentOS Stream 9 -----------------------------------> | | | V V V RHEL-9.1.0 RHEL-9.2.0 RHEL-9.x.0 | | | | | | V V V
The main effect of the blog post I see is that the bug fixes / CVEs that go into RHEL-9.1.z, 9.2.z, 9.x.z streams are no longer going to be freely available - only the initial content of each poinmt release in available from CentOS Stream.
This doesn't impact Fedora, but will certainly impact the various RHEL rebuilds whether community based (AlmaLinux, Rocky Linux), or fully commercial (Oracle OEL). Those distros can still provide the initial point releases, but will have to do all the work to figure out backports for bug fixes/CVEs/etc within the release. This is going to be a serious burden for those distros.
With regards, Daniel
This doesn't impact Fedora, but will certainly impact the various RHEL rebuilds whether community based (AlmaLinux, Rocky Linux), or fully commercial (Oracle OEL). Those distros can still provide the initial point releases, but will have to do all the work to figure out backports for bug fixes/CVEs/etc within the release. This is going to be a serious burden for those distros.
At present Red Hat is the primary sponsor for Fedora. RHEL is one downstream of Fedora, but there are others including Amazon Linux, Alma, Rocky, CentOS, Miracle Linux, Qubes OS, Open Euler, Linpux etc. As a result, Fedora development is healthy and robust, and may cost Red Hat less than other development models. It may be good to evolve the Fedora governance model to recognize other significant contributors (both resources and time), either individually or corporate and provide a means for these contributors to also contribute to the governance of the project should they want to do so.
With regards, Daniel
On 6/21/23 22:26, Gerald Henriksen wrote:
On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:
Hi all,
Obviously many will have seen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
and see, where EL (contributors like you of fedora/EPEL) have been knocked down:
https://bugzilla.redhat.com/show_bug.cgi?id=2215299
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL.
CentOS Stream topic is still confusing to many, thus I am going to use the opportunity to mention two talks which I have provided at FOSDEM 2022 [1] and Open Infra Summit 22 [2] on the matter:
[1] https://archive.fosdem.org/2022/schedule/event/centos_stream_stable_and_cont... [2] https://discussion.fedoraproject.org/t/centos-stream-talk-at-openinfra-summi...
I also have a leaflet version [3] for those who prefer text.
[3] https://gitlab.com/bookwar/centos-leaflet/-/blob/main/centos-leaflet.pdf
----
Part of the confusion comes from the fact that people refer to upstream development, Fedora development and CentOS/RHEL development using just one word - development, while in reality these are three very different activities, and all of them are required for the RHEL existence.
You can not replace upstream with RHEL development, you would have to create new upstream for that. The same way you can not replace Fedora development with RHEL/CentOS Stream development, it is a very different thing and you would need to create it.
The second part comes from thinking of CentOS Stream as something in the middle, between Fedora and RHEL. CentOS Stream is a rebuild of RHEL. It is a rebuild of exactly RHEL sources taken from the same git tree as RHEL builds take those sources. It is not a middle - it is RHEL.
----
So let's look at the sources story closely:
1) How it was before Stream:
there was an internal git tree. RHEL Engineers would commit RHEL changes to that tree, changes would be built into RPM and SRPM. On release, RPM and SRPM would be published for RHEL customers. On that release date CentOS engineers would take the published SRPM, unpack it, and upload the content to the centos git repo.
So CentOS git essentially contained the "exploded SRPMS". No git history was available.
CentOS Engineer then would go to CentOS Koji and build the CentOS package from that exploded source
2) How it was after Stream but Before the announcement:
There is a public git tree on GitLab.com [4] RHEL Engineers commit changes to it. RHEL engineers build CentOS package in public Stream Koji _and_ RHEL package internally from the same git commit. CentOS package becomes public, RHEL package goes into RHEL repository.
[4] https://gitlab.com/redhat/centos-stream/rpms/glibc
As soon as RHEL package is released, the SRPM for a RHEL package becomes available. CentOS Engineer would take that SRPM, unpack it and upload the content to CentOS Git.
But the CentOS package for that RHEL SRPM has already been built weeks ago.
So now we have CentOS package, which is available for weeks in Koji, its sources available for the same two weeks on GitLab [4], with proper git history, MR history, and test history. And then a there is a second set of CentOS sources (exploded rpms, no history), which are not really CentOS sources anymore, because CentOS doesn't build anything from them.
3) So what happened?
- CentOS Engineers will not be producing that git repo of exploded SRPMs anymore because there is no need for them in CentOS project.
- Red Hat recommends to take RHEL sources from CentOS Stream repositories because that is the actual source from which RHEL packages are built by RHEL Engineers.
Can you still get access to SRPMs and create exploded sources repo - Yes. But there is no practical reason for Red Hat or for CentOS Project to maintain such a service.
There is no change in Fedora or with anything related to Fedora.
- So what happened?
- CentOS Engineers will not be producing that git repo of exploded SRPMs
anymore because there is no need for them in CentOS project.
- Red Hat recommends to take RHEL sources from CentOS Stream
repositories because that is the actual source from which RHEL packages are built by RHEL Engineers.
How to interpret it this way; "Red Hat recommends"? Its the other way around! RH does want minimize the source availability by putting stones in the way! This is in line with other activities (kernel patches).
Regarding Dev Account - that can be also disappear in the future!
Furthermore:
Take a look at the Unauthorized Use section
https://www.redhat.com/licenses/Appendix_1_Global_English_20230309.pdf
and "Partner will not use Red Hat Products or >>>Services<<<< to create an offering competitive with Red Hat,"
from
https://www.redhat.com/licenses/Partner_Agreement_Webversion_North_America_E...
The tactic here - not the sources are used against the community its the road to them ("Services")!
This is the cathedral method.
BTW; The sources "state" in gitlab is not stable and "far" away from RH GA releases!
Dne 23. 06. 23 v 12:46 Leon Fauster via devel napsal(a):
- So what happened?
- CentOS Engineers will not be producing that git repo of exploded SRPMs
anymore because there is no need for them in CentOS project.
- Red Hat recommends to take RHEL sources from CentOS Stream
repositories because that is the actual source from which RHEL packages are built by RHEL Engineers.
How to interpret it this way; "Red Hat recommends"? Its the other way around! RH does want minimize the source availability by putting stones in the way! This is in line with other activities (kernel patches).
Regarding Dev Account - that can be also disappear in the future!
Furthermore:
Take a look at the Unauthorized Use section
https://www.redhat.com/licenses/Appendix_1_Global_English_20230309.pdf
and "Partner will not use Red Hat Products or >>>Services<<<< to create an offering competitive with Red Hat,"
from
https://www.redhat.com/licenses/Partner_Agreement_Webversion_North_America_E...
The tactic here - not the sources are used against the community its the road to them ("Services")!
This is the cathedral method.
BTW; The sources "state" in gitlab is not stable and "far" away from RH GA releases!
Please understand that (speaking of the user space packages, I cannot speak for kernel) there are no other sources then the sources in GitLab, which is publicly accessible (AFAIK).
Vít
On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch vondruch@redhat.com wrote:
Please understand that (speaking of the user space packages, I cannot speak for kernel) there are no other sources then the sources in GitLab, which is publicly accessible (AFAIK).
The sources that are actually used for RHEL releases are certainly not available on GitLab. E.g. the latest released version of webkit2gtk3 is currently 2.38.5-1.el9.2. You can try finding the source for that on GitLab, but it's not there because we don't have stable branches on GitLab. CentOS Stream went from 2.38.5-1.el9 to 2.40.1-1.el9.
Dne 23. 06. 23 v 15:34 Michael Catanzaro napsal(a):
On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch vondruch@redhat.com wrote:
Please understand that (speaking of the user space packages, I cannot speak for kernel) there are no other sources then the sources in GitLab, which is publicly accessible (AFAIK).
The sources that are actually used for RHEL releases are certainly not available on GitLab. E.g. the latest released version of webkit2gtk3 is currently 2.38.5-1.el9.2. You can try finding the source for that on GitLab, but it's not there because we don't have stable branches on GitLab. CentOS Stream went from 2.38.5-1.el9 to 2.40.1-1.el9.
Ok, you are right. But there are two things:
1) This was deliberate choice of maintainer, nothing else. Maintainer chosen to skip the 2.38.5 whatever the reason was
2) Does it harm anything to have the 9.3 package sooner the having RHEL 9.3 out? Is it really less stable as was claimed elsewhere in the thread?
Vít
Dne 23. 06. 23 v 18:00 Vít Ondruch napsal(a):
Dne 23. 06. 23 v 15:34 Michael Catanzaro napsal(a):
On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch vondruch@redhat.com wrote:
Please understand that (speaking of the user space packages, I cannot speak for kernel) there are no other sources then the sources in GitLab, which is publicly accessible (AFAIK).
The sources that are actually used for RHEL releases are certainly not available on GitLab. E.g. the latest released version of webkit2gtk3 is currently 2.38.5-1.el9.2. You can try finding the source for that on GitLab, but it's not there because we don't have stable branches on GitLab. CentOS Stream went from 2.38.5-1.el9 to 2.40.1-1.el9.
Or actually. What is the difference between 2.38.5-1.el9.2 and 2.38.5-1.el9 except the dist tag? I probably don't understand. And that might be problem that neither others understand. But I'd assume that only the disttag differs.
Vít
Ok, you are right. But there are two things:
- This was deliberate choice of maintainer, nothing else. Maintainer
chosen to skip the 2.38.5 whatever the reason was
- Does it harm anything to have the 9.3 package sooner the having
RHEL 9.3 out? Is it really less stable as was claimed elsewhere in the thread?
Vít
Dne 23. 06. 23 v 18:14 Vít Ondruch napsal(a):
Dne 23. 06. 23 v 18:00 Vít Ondruch napsal(a):
Dne 23. 06. 23 v 15:34 Michael Catanzaro napsal(a):
On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch vondruch@redhat.com wrote:
Please understand that (speaking of the user space packages, I cannot speak for kernel) there are no other sources then the sources in GitLab, which is publicly accessible (AFAIK).
The sources that are actually used for RHEL releases are certainly not available on GitLab. E.g. the latest released version of webkit2gtk3 is currently 2.38.5-1.el9.2. You can try finding the source for that on GitLab, but it's not there because we don't have stable branches on GitLab. CentOS Stream went from 2.38.5-1.el9 to 2.40.1-1.el9.
Or actually. What is the difference between 2.38.5-1.el9.2 and 2.38.5-1.el9 except the dist tag? I probably don't understand.
Ah, there is actually webkit2gtk3-2.38.5-1.el9_2.2 not webkit2gtk3-2.38.5-1.el9.2. I got it now.
Vít
And that might be problem that neither others understand. But I'd assume that only the disttag differs.
Vít
Ok, you are right. But there are two things:
- This was deliberate choice of maintainer, nothing else. Maintainer
chosen to skip the 2.38.5 whatever the reason was
- Does it harm anything to have the 9.3 package sooner the having
RHEL 9.3 out? Is it really less stable as was claimed elsewhere in the thread?
Vít
On Fri, Jun 23 2023 at 06:16:52 PM +0200, Vít Ondruch vondruch@redhat.com wrote:
Ah, there is actually webkit2gtk3-2.38.5-1.el9_2.2 not webkit2gtk3-2.38.5-1.el9.2. I got it now.
Oh sorry, I mentally expanded the dist tag incorrectly. My bad.
Anyway, in this example, CentOS Stream is on 2.40 while RHEL 9.2 is on 2.38. The RHEL security update is never visible in CentOS Stream because it's not needed there.
Hopefully 2.40 is better overall than 2.38 (and certainly much more secure), but certainly there are always plenty of new regressions and bugs that were not there before. No way to pretend you're bug-compatible with RHEL if you're pulling sources from CentOS Stream.
On Fri, Jun 23, 2023 at 9:35 AM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch vondruch@redhat.com wrote:
Please understand that (speaking of the user space packages, I cannot speak for kernel) there are no other sources then the sources in GitLab, which is publicly accessible (AFAIK).
The sources that are actually used for RHEL releases are certainly not available on GitLab. E.g. the latest released version of webkit2gtk3 is currently 2.38.5-1.el9.2. You can try finding the source for that on GitLab, but it's not there because we don't have stable branches on GitLab. CentOS Stream went from 2.38.5-1.el9 to 2.40.1-1.el9.
Which means equivalent fixes are in CentOS Stream and anyone wanting to recreate exactly what is in RHEL is welcome to backport that code from CentOS Stream or upstream.
josh
On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer jwboyer@fedoraproject.org wrote:
Which means equivalent fixes are in CentOS Stream and anyone wanting to recreate exactly what is in RHEL is welcome to backport that code from CentOS Stream or upstream.
Yes, but that's going to be pretty hard to do if you cannot see what needs to be backported because you don't have a Customer Portal subscription. :)
In this particular case, there are two CVEs fixed somewhere in the middle of maybe 100 other upstream changes, and the correspondence between CVE vs. upstream commit is intentionally not public to discourage distros from backporting individual security fixes. (It's not a smart idea. Only 5% of WebKit security bugs get CVEs. I sometimes do security backports for RHEL anyway for regulatory rather than security reasons.) Anyway, to figure out what to backport in order to match what's in RHEL, you'd have to either somehow get access to the RHEL SRPM, or else email me and ask what to do.
I don't really have any strong opinion about this change. Just pointing out that it's going to be effectively impossible to reverse-engineer RHEL from CentOS Stream. Let's not pretend that's realistic. Rebuilders are going to need to get copies of the RHEL SRPMs somehow if they want to match RHEL, and they do.
Michael
On Fri, Jun 23, 2023, 3:20 PM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer jwboyer@fedoraproject.org wrote:
Which means equivalent fixes are in CentOS Stream and anyone wanting to recreate exactly what is in RHEL is welcome to backport that code from CentOS Stream or upstream.
Yes, but that's going to be pretty hard to do if you cannot see what needs to be backported because you don't have a Customer Portal subscription. :)
Yes, the work you do is not easy.
In this particular case, there are two CVEs fixed somewhere in the
middle of maybe 100 other upstream changes, and the correspondence between CVE vs. upstream commit is intentionally not public to discourage distros from backporting individual security fixes. (It's not a smart idea. Only 5% of WebKit security bugs get CVEs. I sometimes do security backports for RHEL anyway for regulatory rather than security reasons.) Anyway, to figure out what to backport in order to match what's in RHEL, you'd have to either somehow get access to the RHEL SRPM, or else email me and ask what to do.
Or build up a knowledge of the code base that allows one to do it themselves.
I don't really have any strong opinion about this change. Just pointing
out that it's going to be effectively impossible to reverse-engineer RHEL from CentOS Stream. Let's not pretend that's realistic. Rebuilders are going to need to get copies of the RHEL SRPMs somehow if they want to match RHEL, and they do.
I don't think it's impossible. I think it requires work, skill, and investment.
josh
On Fri, Jun 23, 2023, 18:41 Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, Jun 23, 2023, 3:20 PM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer jwboyer@fedoraproject.org wrote:
Which means equivalent fixes are in CentOS Stream and anyone wanting to recreate exactly what is in RHEL is welcome to backport that code from CentOS Stream or upstream.
Yes, but that's going to be pretty hard to do if you cannot see what needs to be backported because you don't have a Customer Portal subscription. :)
Yes, the work you do is not easy.
In this particular case, there are two CVEs fixed somewhere in the
middle of maybe 100 other upstream changes, and the correspondence between CVE vs. upstream commit is intentionally not public to discourage distros from backporting individual security fixes. (It's not a smart idea. Only 5% of WebKit security bugs get CVEs. I sometimes do security backports for RHEL anyway for regulatory rather than security reasons.) Anyway, to figure out what to backport in order to match what's in RHEL, you'd have to either somehow get access to the RHEL SRPM, or else email me and ask what to do.
Or build up a knowledge of the code base that allows one to do it themselves.
I don't really have any strong opinion about this change. Just pointing
out that it's going to be effectively impossible to reverse-engineer RHEL from CentOS Stream. Let's not pretend that's realistic. Rebuilders are going to need to get copies of the RHEL SRPMs somehow if they want to match RHEL, and they do.
I don't think it's impossible. I think it requires work, skill, and investment.
if only that time, skill, and investment wasn't doing useless re-work, and could be spent on contributing to Stream.
josh _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Yep! I (We) spend a lot of unpaid time to provide EL bug reports, helping the devs to test their fixes, until it gets into the next EL minor release. Especially when a new major EL release is GA, it has a lot of bugs that I normally do report (doing it since EL5 personally). This is sometimes only possible when having the source code to test some patches before adding them to the report. Despite the argument that the srpms are available in the portal area, I wonder if the mentioned decision had included this "tacit" input that is coming from the "community". Not having such input in combination with a reduced community will for sure have a negative impact. I'm already reading statements from Fedora maintainers of their EPEL backtracks and I can imagine that the same is happening for less visible contributions ...
On 6/23/23 15:20, Michael Catanzaro wrote:
On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer jwboyer@fedoraproject.org wrote:
Which means equivalent fixes are in CentOS Stream and anyone wanting to recreate exactly what is in RHEL is welcome to backport that code from CentOS Stream or upstream.
Yes, but that's going to be pretty hard to do if you cannot see what needs to be backported because you don't have a Customer Portal subscription. :)
In this particular case, there are two CVEs fixed somewhere in the middle of maybe 100 other upstream changes, and the correspondence between CVE vs. upstream commit is intentionally not public to discourage distros from backporting individual security fixes. (It's not a smart idea. Only 5% of WebKit security bugs get CVEs. I sometimes do security backports for RHEL anyway for regulatory rather than security reasons.) Anyway, to figure out what to backport in order to match what's in RHEL, you'd have to either somehow get access to the RHEL SRPM, or else email me and ask what to do.
I don't really have any strong opinion about this change. Just pointing out that it's going to be effectively impossible to reverse-engineer RHEL from CentOS Stream. Let's not pretend that's realistic. Rebuilders are going to need to get copies of the RHEL SRPMs somehow if they want to match RHEL, and they do.
For WebKit specifically, my recommendation is to just take the latest version from upstream, since anything else will be missing critical security patches. I would be highly surprised if Red Hat has patches that add any significant value there. This is even more true for Firefox, since Firefox is a leaf package.
For upstreams as complex, fast-moving, and exposed as browser engines, trying to backport fixes is a fool’s errand. Just take what upstream provides and ship it. If one needs patches for legal reasons, upstream those and ship the result. And yes, in the case of Chromium that does mean using a clang binary built from the same sources as the one Google provides. Every hour needed to ship a patch is one hour the attackers have to write and deploy an exploit.
On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen ghenriks@gmail.com wrote:
On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:
Hi all,
Obviously many will have seen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
and see, where EL (contributors like you of fedora/EPEL) have been knocked down:
https://bugzilla.redhat.com/show_bug.cgi?id=2215299
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL.
Just to interject, this is an incorrect interpretation. Red Hat is still highly committed to Fedora (as evidenced by the continued support for Fedora ELN as the integration path from Rawhide to CentOS Stream).
Am 22.06.23 um 16:08 schrieb Stephen Gallagher:
On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen ghenriks@gmail.com wrote:
On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:
Hi all,
Obviously many will have seen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
and see, where EL (contributors like you of fedora/EPEL) have been knocked down:
https://bugzilla.redhat.com/show_bug.cgi?id=2215299
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat?
My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL.
Just to interject, this is an incorrect interpretation.
But is Red Hat still commited to open source and to the freedom of software?
I feel no and feel cheated and betrayed.
Ralf
On Thu, Jun 22, 2023, at 6:32 PM, Ralf Corsépius wrote:
But is Red Hat still commited to open source and to the freedom of software?
I feel no and feel cheated and betrayed.
Hey Ralf,
why do you feel that way? The sources are still available both upstream (CentOS) and downstream (albeit behind a login wall or through your installed RHEL).
Regards,
Simon
On 2023-06-21 13:06, Philip Wyett wrote:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream ... I see an impasse here. Why contribute to fedora when Red Hat will lock it down in other products?
I don't think this is a major change from the status quo.
In the past, Red Hat has published a subset of the git repositories used to create RHEL. They have published spec and patches used to create the current minor release of each major, but nothing from the EUS or SAP support periods. That is, they haven't published any updates to any branch other than the latest branch they publish. There is only one available branch at any time.
Now that Stream is available, the same thing is (apparently) true. At least, as best as I understand their announcement. There will be just one available branch, and that branch will contain the spec and patches used to create the latest packages.
On 6/22/23 06:21, Gordon Messmer wrote:
On 2023-06-21 13:06, Philip Wyett wrote:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream ... I see an impasse here. Why contribute to fedora when Red Hat will lock it down in other products?
I don't think this is a major change from the status quo.
In the past, Red Hat has published a subset of the git repositories used to create RHEL. They have published spec and patches used to create the current minor release of each major, but nothing from the EUS or SAP support periods. That is, they haven't published any updates to any branch other than the latest branch they publish. There is only one available branch at any time.
Now that Stream is available, the same thing is (apparently) true. At least, as best as I understand their announcement. There will be just one available branch, and that branch will contain the spec and patches used to create the latest packages.
That's how I understand it well and I'm a bit confused what's the "fuss" about. The git.centos.org mirrored sources that were used to build CentOS. Since CentOS is no longer supported, and we have the CentOS Stream, the same is true - the sources are still available, just at different location [0]. So this doesn't seem like RH is "locking things down", just getting rid of things that are not needed anymore.
Note that I'm in a no way endorsing the change, I'm just trying to understand what's the big deal (if there's any).
[0] https://gitlab.com/redhat/centos-stream/rpms [1] https://vault.centos.org/centos/8-stream/
On 6/22/23 06:21, Gordon Messmer wrote:
That's how I understand it well and I'm a bit confused what's the "fuss" about. The git.centos.org mirrored sources that were used to build CentOS. Since CentOS is no longer supported, and we have the CentOS Stream, the same is true - the sources are still available, just at different location [0]. So this doesn't seem like RH is "locking things down", just getting rid of things that are not needed anymore.
Note that I'm in a no way endorsing the change, I'm just trying to understand what's the big deal (if there's any).
[0] https://gitlab.com/redhat/centos-stream/rpms [1] https://vault.centos.org/centos/8-stream/
The big deal is that it sends wrong signals at the wrong time. Within the last few weeks, we had out of the blue (pun intended): - Lay-off of the Fedora Program Manager - Dropping LO packages and dependencies the hard way (orphan first, announce later when the rubbles are crumbling) - Retreating from GPL's source distribution requirement to the bare minimum (or less, I'm no lawyer)
In each case, the way it was done and communicated was literally begging for bad press.
In the specific case of RHEL srpms, it makes life harder for EPEL packagers because you can't look at the source easily when they are problems between RHEL and EPEL packages. It matches well with RH's standard of shipping libraries without headers etc - it is easier for them and limits the scope of support contracts but makes upstream's life harder.
So, the signal is either "we don't care about our upstream" or "we do not understand upstream's importance and concerns".
And that is why packagers may consider dropping EPEL branches and let RH pick from Fedora what they want - at the expense of having to support it themselves. That will reduce RHEL to a pure enterprise distribution without community. Is that what their customers want?
Groundhog day.
On Thu, Jun 22, 2023 at 08:44:13AM -0000, Michael J Gruber wrote:
In the specific case of RHEL srpms, it makes life harder for EPEL packagers because you can't look at the source easily when they are problems between RHEL and EPEL packages. It matches well with RH's standard of shipping libraries without headers etc - it is easier for them and limits the scope of support contracts but makes upstream's life harder.
EPEL packagers should have easy access to RHEL through the no-cost subscription program. Or, reasonably easy -- I'm aware that the developer portal hoops are more... hoopy... than would be idea. But once set up, it shouldn't be difficult. If you _are_ finding rough spots in that, I can raise the issues and see if we can make things beter.
22/06/23 11:06, Matthew Miller wrote:
On Thu, Jun 22, 2023 at 08:44:13AM -0000, Michael J Gruber wrote:
In the specific case of RHEL srpms, it makes life harder for EPEL packagers because you can't look at the source easily when they are problems between RHEL and EPEL packages. It matches well with RH's standard of shipping libraries without headers etc - it is easier for them and limits the scope of support contracts but makes upstream's life harder.
EPEL packagers should have easy access to RHEL through the no-cost subscription program.
Why should we keep contributing to EPEL? To be forced to use 16 free RHEL instances maximum? What is the advantage for us volunteer contributors? I mean, we did not do it for personal advantage, we did it to help us each other within the Enterprise Linux distros community, but this Red Hat move will kill the Enterprise Linux distros community, leaving only with RHEL, which is mostly a paid subscription distribution, let's call things with their proper name
Dne 22. 06. 23 v 10:44 Michael J Gruber napsal(a):
In each case, the way it was done and communicated was literally begging for bad press. ...
So, the signal is either "we don't care about our upstream" or "we do not understand upstream's importance and concerns".
None of the last two. It is first one out of these three: wrongly communicated and begging for bad press.
I think that RH engineers are pretty bad in communicating things. Me included.
I'm a Red Hat employed engineer, working on all Fedora, CentOS Stream and RHEL. This is what each means for me in particular (but should also be applicable in general) in practice:
* RHEL - only when I'm bound by some legal requirement (embargo, etc.) I do work 'RHEL only' (not visible in CentOS stream). In practice, such work is expected to be seen in CentOS Stream once the legal barrier falls / expires.
* CentOS Stream - all work (except abovementioned) for RHEL is done here. The code has been available here (for 2 years already for C9S): https://gitlab.com/redhat/centos-stream/ Are you missing anything? (codebase-wise) This means my work on RHEL is visible unlike ever before. Open to submissions via merge requests Also merge requests where I develop changes are open to examination during my development of them. (unlike anytime before)
* Fedora - unlike RHEL or CentOS, this is the place where I can develop new features. I don't have this space downstream. So tuning packaging, trying out various enhancements, adopting big upstream changes, packing latest greatest upstream releases. All that will be branched to form a new RHEL one day. This is the only way for me to introduce big changes. As I see it, both RHEL and Fedora profit from that to maximum.
And I don't expect this relationship to go away anytime soon.
However I might have misunderstood the core of this discussion.
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On Thu, Jun 22, 2023 at 11:39 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 22. 06. 23 v 10:44 Michael J Gruber napsal(a):
In each case, the way it was done and communicated was literally begging for bad press. ...
So, the signal is either "we don't care about our upstream" or "we do not understand upstream's importance and concerns".
None of the last two. It is first one out of these three: wrongly communicated and begging for bad press.
I think that RH engineers are pretty bad in communicating things. Me included.
-- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-
Aleksandra Fedorova -
Andreas Tunek -
Ben Cotton -
Benson Muite -
Carlos Rodriguez-Fernandez -
Chris Adams -
Clemens Lang -
Daniel P. Berrangé -
Demi Marie Obenour -
Dominik 'Rathann' Mierzejewski -
František Šumšal -
Gary Buhrmaster -
Gerald Henriksen -
Germano Massullo -
Gordon Messmer -
Ian Laurie -
Jonathan Steffan -
Josh Boyer -
JT -
Kevin Kofler -
Leon Fauster -
Leslie Satenstein -
Matthew Miller -
Mattia Verga -
Michael Catanzaro -
Michael J Gruber -
Michal Schorm -
Miroslav Suchý -
Neal Gompa -
Neil Hanlon -
Philip Wyett -
Ralf Corsépius -
Simon de Vlieger -
Smith, Stewart -
Stephen Gallagher -
Tomasz Torcz -
Vitaly Zaitsev -
Vít Ondruch