What is Fedora?

[Philip Wyett]

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

[JT]

>  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(a)kathenas.org&gt;
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>

[Philip Wyett]

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

[JT]

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(a)kathenas.org&gt;
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
>

[Philip Wyett]

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

[JT]

>   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(a)kathenas.org&gt;
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
>

[Philip Wyett]

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

[JT]

>   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(a)kathenas.org&gt;
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
>

[Philip Wyett]

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(a)kathenas.org&gt; 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

[JT]

>   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(a)kathenas.org&gt;
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(a)kathenas.org&gt;
>  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
>

[Philip Wyett]

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

-- 
*** 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

[Gerald Henriksen]

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.

[Philip Wyett]

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

-- 
*** 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

[Ben Cotton]

On Wed, Jun 21, 2023 at 4:07 PM Philip Wyett <philip.wyett(a)kathenas.org&gt; 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(a)gmail.com&gt; 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).

-- 
Ben Cotton (he/him)
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/User:Bcotton

[Philip Wyett]

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(a)kathenas.org&gt; 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(a)gmail.com&gt; 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

[Ben Cotton]

On Wed, Jun 21, 2023 at 5:09 PM Philip Wyett <philip.wyett(a)kathenas.org&gt; 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.

-- 
Ben Cotton (he/him)
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/User:Bcotton

[Philip Wyett]

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(a)kathenas.org&gt; 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

-- 
*** 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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Matthew Miller]

> > 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.) 



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Josh Boyer]

On Thu, Jun 22, 2023 at 5:02 AM Matthew Miller <mattdm(a)fedoraproject.org&gt; 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:
>
>  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.) 
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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Kevin Kofler]

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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Neal Gompa]

On Fri, Jun 23, 2023 at 6:09 PM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; 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-t...

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...

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.


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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Chris Adams]

Once upon a time, Neal Gompa <ngompa13(a)gmail.com&gt; 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.

-- 
Chris Adams <linux(a)cmadams.net&gt;

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Michael Catanzaro]

On Sat, Jun 24 2023 at 08:53:32 AM -0500, Chris Adams 
<linux(a)cmadams.net&gt; 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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Chris Adams]

Once upon a time, Michael Catanzaro <mcatanzaro(a)redhat.com&gt; 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).

-- 
Chris Adams <linux(a)cmadams.net&gt;

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Michael Catanzaro]

On Sat, Jun 24 2023 at 10:24:58 AM -0500, Chris Adams 
<linux(a)cmadams.net&gt; 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.

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Aleksandra Fedorova]

Hi,

On Sat, Jun 24, 2023 at 6:09 PM Michael Catanzaro <mcatanzaro(a)redhat.com&gt;
wrote:

>  On Sat, Jun 24 2023 at 10:24:58 AM -0500, Chris Adams
>  <linux(a)cmadams.net&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
-- 
Aleksandra Fedorova
bookwar

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Chris Adams]

Once upon a time, Aleksandra Fedorova <alpha(a)bookwar.info&gt; 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.
>  
>  https://kojihub.stream.centos.org/koji/taginfo?tagID=2 
That's not available as a repo though AFAIK.
-- 
Chris Adams <linux(a)cmadams.net&gt;

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Aleksandra Fedorova]

On Sat, Jun 24, 2023 at 6:36 PM Chris Adams <linux(a)cmadams.net&gt; wrote:

>  Once upon a time, Aleksandra Fedorova <alpha(a)bookwar.info&gt;
> 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.
>  >
>  > https://kojihub.stream.centos.org/koji/taginfo?tagID=2
>
>  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(a)cmadams.net&gt;
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Aleksandra Fedorova
bookwar

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Chris Adams]

Once upon a time, Aleksandra Fedorova <alpha(a)bookwar.info&gt; 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).

-- 
Chris Adams <linux(a)cmadams.net&gt;

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Leon Fauster]

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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Gary Buhrmaster]

On Sat, Jun 24, 2023 at 3:05 PM Michael Catanzaro <mcatanzaro(a)redhat.com&gt; 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.

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Michael Catanzaro]

On Sat, Jun 24 2023 at 03:26:46 PM +0000, Gary Buhrmaster 
<gary.buhrmaster(a)gmail.com&gt; 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.

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Smith, Stewart]

On Jun 24, 2023, at 8:05 AM, Michael Catanzaro <mcatanzaro(a)redhat.com&gt; wrote:
>  
>  On Sat, Jun 24 2023 at 08:53:32 AM -0500, Chris Adams
>  <linux(a)cmadams.net&gt; 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?

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Michael Catanzaro]

On Sun, Jul 2 2023 at 09:53:30 PM +0000, "Smith, Stewart via devel" 
<devel(a)lists.fedoraproject.org&gt; 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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Demi Marie Obenour]

On 6/24/23 11:05, Michael Catanzaro wrote:
>  
>  On Sat, Jun 24 2023 at 08:53:32 AM -0500, Chris Adams 
>  <linux(a)cmadams.net&gt; 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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Michael Catanzaro]

On Sun, Jul 2 2023 at 06:27:48 PM -0400, Demi Marie Obenour 
<demiobenour(a)gmail.com&gt; 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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Leon Fauster]

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(a)gmail.com&gt; 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.

-- 
Leon

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Gordon Messmer]

On 2023-06-24 06:53, Chris Adams wrote:
>  Once upon a time, Neal Gompa<ngompa13(a)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.

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Leon Fauster]

>  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".

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Clemens Lang]

Hi Leon,

>  On 24. Jun 2023, at 19:44, Leon Fauster via devel
> <devel(a)lists.fedoraproject.org&gt; 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_:
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=2184640 
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.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Kevin Kofler]

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:
>  
>  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-t...
>  
>  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...
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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Dominik 'Rathann' Mierzejewski]

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:
>  > 
>  > 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-t...
>  > 
>  > 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...
>  
>  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
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Gordon Messmer]

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.

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Kevin Kofler]

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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Ian Laurie]

On 6/22/23 19:01, Matthew Miller wrote:
>  Sure, but... that's the _opposite_ of the direction things are
> going. 
Awesome post.

-- 
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Simon de Vlieger]

On Thu, Jun 22, 2023, at 11:01 AM, Matthew Miller wrote:

>  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: 
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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Jonathan Steffan]

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(a)supakeen.com&gt; wrote:

>  On Thu, Jun 22, 2023, at 11:01 AM, Matthew Miller wrote:
>
>  > 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:
>
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Jonathan Steffan
jonathansteffan(a)gmail.com

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Smith, Stewart]

>  On Jun 22, 2023, at 2:01 AM, Matthew Miller
> <mattdm(a)fedoraproject.org&gt; 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:
>  
>  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.
>  
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:
>  
>  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.
>  
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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Kevin Kofler]

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-20...

        Kevin Kofler

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Tomasz Torcz]

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-20...
 SUSE too, but it is not so funny as Oracle's
 https://www.suse.com/news/SUSE-Preserves-Choice-in-Enterprise-Linux/

-- 
Tomasz Torcz                “Funeral in the morning, IDE hacking
tomek(a)pipebreaker.pl         in the afternoon and evening.” - Alan Cox

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Andreas Tunek]

Den tis 11 juli 2023 kl 12:49 skrev Kevin Kofler via devel <
devel(a)lists.fedoraproject.org&gt;:

>  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-20...
>
>          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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Michael J Gruber]

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-20...
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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Mattia Verga]

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-20... Kevin
> Kofler _______________________________________________ devel mailing list --
> devel(a)lists.fedoraproject.org To unsubscribe send an email to
> devel-leave(a)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/[e-mail] Do not reply
> to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Andreas Tunek]

Den tis 11 juli 2023 kl 19:12 skrev Mattia Verga via devel <
devel(a)lists.fedoraproject.org&gt;:

>  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(a)lists.fedoraproject.org&gt; 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-20...
>  Kevin Kofler _______________________________________________ devel mailing
>  list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to
>  devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>
>

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Chris Adams]

Once upon a time, Mattia Verga <mattia.verga(a)proton.me&gt; 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.

-- 
Chris Adams <linux(a)cmadams.net&gt;

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Leon Fauster]

Am 11.07.23 um 21:02 schrieb Chris Adams:
>  Once upon a time, Mattia Verga <mattia.verga(a)proton.me&gt; 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

-- 
Leon

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Michael Catanzaro]

On Tue, Jul 11 2023 at 09:18:57 PM +0200, Leon Fauster via devel 
<devel(a)lists.fedoraproject.org&gt; 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

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Leslie Satenstein]

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(a)lists.fedoraproject.org&gt; 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-20...

        Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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/[e-mail]
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Carlos Rodriguez-Fernandez]

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(a)lists.fedoraproject.org&gt; 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-20...
> <https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-20...
>  
>           Kevin Kofler
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org 
>  <mailto:[e-mail]>
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 
>  <mailto:[e-mail]>
>  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/[e-mail]
> <https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Vitaly Zaitsev]

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

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Carlos Rodriguez-Fernandez]

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.

CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Kevin Kofler]

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...

        Kevin Kofler

[Stephen Gallagher]

On Wed, Jun 21, 2023 at 5:46 PM Philip Wyett <philip.wyett(a)kathenas.org&gt; 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(a)kathenas.org&gt;
> 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.

[Gordon Messmer]

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.

[Daniel P. Berrangé]

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Vitaly Zaitsev]

On 22/06/2023 10:11, Daniel P. Berrangé wrote:
>  Nothing described in that blog post above changes this process, so
>  what's written there doesn't have any direct impact on Fedora. 
Yet.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Benson Muite]

>  
>  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

[Aleksandra Fedorova]

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_c...
[2] 
https://discussion.fedoraproject.org/t/centos-stream-talk-at-openinfra-su...

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.

-- 
Aleksandra Fedorova,
member of Fedora Council
RHEL/CentOS Strem CI Engineer
bookwar on Matrix

>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Leon Fauster]

>  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. 
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_Americ...

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!

[Vít Ondruch]

Dne 23. 06. 23 v 12:46 Leon Fauster via devel napsal(a):
> > 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.
>  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_Americ...
>
>  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

[Michael Catanzaro]

On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch 
<vondruch(a)redhat.com&gt; 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.

[Vít Ondruch]

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(a)redhat.com&gt; 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

[Vít Ondruch]

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(a)redhat.com&gt; 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:
>
>  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
>
>

[Vít Ondruch]

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(a)redhat.com&gt; 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:
> >
> > 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
> >
>

[Michael Catanzaro]

On Fri, Jun 23 2023 at 06:16:52 PM +0200, Vít Ondruch 
<vondruch(a)redhat.com&gt; 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.

[Josh Boyer]

On Fri, Jun 23, 2023 at 9:35 AM Michael Catanzaro <mcatanzaro(a)redhat.com&gt; wrote:
>  On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch
>  <vondruch(a)redhat.com&gt; 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

[Michael Catanzaro]

On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer 
<jwboyer(a)fedoraproject.org&gt; 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

[Josh Boyer]

On Fri, Jun 23, 2023, 3:20 PM Michael Catanzaro <mcatanzaro(a)redhat.com&gt;
wrote:

>  On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer
>  <jwboyer(a)fedoraproject.org&gt; 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

[Neil Hanlon]

On Fri, Jun 23, 2023, 18:41 Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:

>  On Fri, Jun 23, 2023, 3:20 PM Michael Catanzaro <mcatanzaro(a)redhat.com&gt;
>  wrote:
>
> > On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer
> > <jwboyer(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Leon Fauster]

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 ...

[Demi Marie Obenour]

On 6/23/23 15:20, Michael Catanzaro wrote:
>  On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer 
>  <jwboyer(a)fedoraproject.org&gt; 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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Leon Fauster]

https://access.redhat.com/security/updates/backporting/

[Stephen Gallagher]

On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen <ghenriks(a)gmail.com&gt; 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).

[Ralf Corsépius]

Am 22.06.23 um 16:08 schrieb Stephen Gallagher:
>  On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen
> <ghenriks(a)gmail.com&gt; 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

[Simon de Vlieger]

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

[Gordon Messmer]

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.

[František Šumšal]

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/


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B

[Michael J Gruber]

>  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.

[Matthew Miller]

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.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Germano Massullo]

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

[Miroslav Suchý]

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

[Michal Schorm]

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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue