undefined | Better HN

0 pointsderekp75y ago0 comments

The problem isn't the 5 years. It is the fact that Stream will have packages more towards the leading edge and potentially have more bugs. Then, when a bug is found in a package, RHEL gets the patch first, but then the patch needs to be re-worked to get it to apply against the newer version of the package that is in Stream. I don't know if the wall will still exist between CentOS and RHEL teams, where CentOS won't know of a(n) (embargoed) patch that RHEL has prior to public release. If they don't, then potentially something like Rocky will get the patch before Stream (due to the above mentioned re-working of the patch).

Now if that firewall between the two groups gets some holes poked in it, where Stream can start working with the patch sets prior to release on RHEL, then it may not be such an issue.

0 comments

2 comments · 2 top-level

bayindirh5y ago

> (if) Stream can start working with the patch sets prior to release on RHEL, then it may not be such an issue...

From the chats I had with people who work either on RH or Fedora, CentOS Stream is actually RHEL's next point release's candidate version.

In practicality, CentOS will move from RHEL-1 to RHEL+1 with security patches included.

We're one of the parties get pretty burned by this, but things look better than the start. We'll see.

mekster5y ago

Are you just guessing that third parties have enough resource to release proper patches quicker?

Not sure what the "rework" is about when a bug is found in Stream, the "rework" is toward older versions of the package in RHEL.

I always wonder how the statements to dismiss Stream is quite weak.

j / k navigate · click thread line to collapse