OK, we realized that the changes are final, and must somehow deal with it. Before making final decisions we need some answers.
1. What about bugs and security issues? The FAQ says: "Security issues will be updated in CentOS Stream after they are solved in the current RHEL release."
Consider the scenario: a bug or security issue found in both Stream and current RHEL. It was fixed in RHEL in a few days. How fast it will be fixed in Stream? Obviously, it needs some time to port the fix to newer version of package. Days or months?
Another scenario: a bug or security issue found in Stream but NOT in current RHEL. How fast it will be fixed in Stream? In a few days or in next RHEL release (up to 6 months)?
2. What to do in 2024, when Stream 8 is EOL. Perform full reinstall of all servers to Stream 9? Or there will be some kind of major version upgrade?
A note about hardware: we don't know now what drivers will be dropped from RHEL and Stream 9. Bad news for server owners: in 2024 they may be forced to upgrade hardware or move to RHEL 8 because of its longer lifecycle.
On 12/17/20 6:26 AM, Andrey wrote:
OK, we realized that the changes are final, and must somehow deal with it. Before making final decisions we need some answers.
- What about bugs and security issues? The FAQ says: "Security issues
will be updated in CentOS Stream after they are solved in the current RHEL release."
Developers will somehow decide there is a security issue to fix .. just like they do now.
They will fix that specific issue first in the current RHEL (just like they do now). Once they release that fix (after QA), they will then look to add the fixes into CentOS Stream. From a timing perspective this is no different than the way current CentOS Linux gets security updates (once Red Hat 'releases' the fix the source code is released). This will be the same for any other 'source code rebuild) as well.
Consider the scenario: a bug or security issue found in both Stream and current RHEL. It was fixed in RHEL in a few days. How fast it will be fixed in Stream? Obviously, it needs some time to port the fix to newer version of package. Days or months?
It 'SHOULD' happen within a very short time (few days) .. because, Stream builds against itself. Not building against the latest fixes breaks OTHER items in Stream, Therefore, developers will release items into stream as soon as possible so they can build items against it .. future RHEL development DEPENDS on it.
Another scenario: a bug or security issue found in Stream but NOT in current RHEL. How fast it will be fixed in Stream? In a few days or in next RHEL release (up to 6 months)?
Same answer as above, for the same reason.
- What to do in 2024, when Stream 8 is EOL. Perform full reinstall of
all servers to Stream 9? Or there will be some kind of major version upgrade?
I don't know. I do know that CentOS Linux never had that. If you currently move from CentOS Linux 6 to CentOS Linux 7, that is a manual move. This really is because the versions are significantly different and inplace updates usually fail because data also needs to be adjusted.
Different configurations are usually required for many different server items (httpd, postgresql, mariadb etc.). There are different version of PHP and PERL .. so your scripts need to be rewritten, etc.
It is almost always much better as an admin to stand up the new os .. move a subset of data over and fix it to work .. then moce after that to fix all the issues.
A note about hardware: we don't know now what drivers will be dropped from RHEL and Stream 9. Bad news for server owners: in 2024 they may be forced to upgrade hardware or move to RHEL 8 because of its longer lifecycle.
I doubt that will be the case for most items. We also have a centos-plus kernel that fixes some things.
CentOS also has Special Interest Groups. Want the start one that rolls in the latest Kernel.org kernel and makes it available on stream .. you (or any other member of the community) can do that and build it on CentOS infrastructure. I mean .. SIGs need a group of people and it helps if someone in that group has some community build experience, but if there is enough interest and volunteers and they convince the board the are able to build and will maintain the SIG, it should not be a problem.
There should be at least 2 years of development between versions of CentOS Stream .. CentOS Stream 8 ends in 2024 .. CentOS Stream 9 will release sometime in 2021.
On Thu, Dec 17, 2020 at 03:26:50PM +0300, Andrey wrote:
Consider the scenario: a bug or security issue found in both Stream and current RHEL. It was fixed in RHEL in a few days. How fast it will be fixed in Stream? Obviously, it needs some time to port the fix to newer version of package. Days or months?
I think you're pre-supposing that many packages in Stream will be ahead of RHEL. That's not the case. In most situations here, the package version in Stream will be identical to the one in RHEL. In cases where Stream is ahead, in some cases the security fix will be include moving the RHEL package ahead as well to match. In cases where that's too big of a change, the Stream package will still need to be updated so that a regression doesn't happen in the next RHEL minor.
On 12/17/20 12:11 PM, Matthew Miller wrote:
On Thu, Dec 17, 2020 at 03:26:50PM +0300, Andrey wrote:
Consider the scenario: a bug or security issue found in both Stream and current RHEL. It was fixed in RHEL in a few days. How fast it will be fixed in Stream? Obviously, it needs some time to port the fix to newer version of package. Days or months?
I think you're pre-supposing that many packages in Stream will be ahead of RHEL. That's not the case. In most situations here, the package version in Stream will be identical to the one in RHEL. In cases where Stream is ahead, in some cases the security fix will be include moving the RHEL package ahead as well to match. In cases where that's too big of a change, the Stream package will still need to be updated so that a regression doesn't happen in the next RHEL minor.
Adding to Matthew's point .. My reply was for things that are different (as that is what you initially asked). Some things will be and others will not be.
But also on the positive side.. Many times though IF a Stream package is newer, the upstream project that maintains the newer code will have already rolled in the change (think a re-base of Gnome, LibreOffice or some other package set). So there may be times when security fixes actually happen first in Stream. That will not be the goal or the default situation, but it will from time to time happen on a re-base of packages.
Am 17.12.20 um 21:13 schrieb Johnny Hughes:
On 12/17/20 12:11 PM, Matthew Miller wrote:
On Thu, Dec 17, 2020 at 03:26:50PM +0300, Andrey wrote:
Consider the scenario: a bug or security issue found in both Stream and current RHEL. It was fixed in RHEL in a few days. How fast it will be fixed in Stream? Obviously, it needs some time to port the fix to newer version of package. Days or months?
I think you're pre-supposing that many packages in Stream will be ahead of RHEL. That's not the case. In most situations here, the package version in Stream will be identical to the one in RHEL. In cases where Stream is ahead, in some cases the security fix will be include moving the RHEL package ahead as well to match. In cases where that's too big of a change, the Stream package will still need to be updated so that a regression doesn't happen in the next RHEL minor.
Adding to Matthew's point .. My reply was for things that are different (as that is what you initially asked). Some things will be and others will not be.
But also on the positive side.. Many times though IF a Stream package is newer, the upstream project that maintains the newer code will have already rolled in the change (think a re-base of Gnome, LibreOffice or some other package set). So there may be times when security fixes actually happen first in Stream. That will not be the goal or the default situation, but it will from time to time happen on a re-base of packages.
corresponding to Matthew's point; when the sec fix must be incorporated into stream before the next point release, when will this happen? X day/weeks after RHELx.n RHSA or short before RHELx.n+1?
-- Leon
On 12/17/20 3:14 PM, Leon Fauster via CentOS wrote:
Am 17.12.20 um 21:13 schrieb Johnny Hughes:
On 12/17/20 12:11 PM, Matthew Miller wrote:
On Thu, Dec 17, 2020 at 03:26:50PM +0300, Andrey wrote:
Consider the scenario: a bug or security issue found in both Stream and current RHEL. It was fixed in RHEL in a few days. How fast it will be fixed in Stream? Obviously, it needs some time to port the fix to newer version of package. Days or months?
I think you're pre-supposing that many packages in Stream will be ahead of RHEL. That's not the case. In most situations here, the package version in Stream will be identical to the one in RHEL. In cases where Stream is ahead, in some cases the security fix will be include moving the RHEL package ahead as well to match. In cases where that's too big of a change, the Stream package will still need to be updated so that a regression doesn't happen in the next RHEL minor.
Adding to Matthew's point .. My reply was for things that are different (as that is what you initially asked). Some things will be and others will not be.
But also on the positive side.. Many times though IF a Stream package is newer, the upstream project that maintains the newer code will have already rolled in the change (think a re-base of Gnome, LibreOffice or some other package set). So there may be times when security fixes actually happen first in Stream. That will not be the goal or the default situation, but it will from time to time happen on a re-base of packages.
corresponding to Matthew's point; when the sec fix must be incorporated into stream before the next point release, when will this happen? X day/weeks after RHELx.n RHSA or short before RHELx.n+1?
As I have stated again and again .. all changes (security or not) will be incorporated ASAP. Because, this is the build root for development .. not rolling in things is not an option as OTHER things will be built against what is there. Not having things in the build root renders other pieces invalid. So, things will not be held back.
Red Hat is going to an open development model for RHEL using CentOS Stream.
On 2020-12-17 13:30, Johnny Hughes wrote:
Red Hat is going to an open development model for RHEL using CentOS Stream.
will it be something similar hp is doing with clearOS development?
https://www.clearos.com/products/clearos-editions/clearos-7-compare-editions
On 12/17/20 3:04 AM, edward via CentOS wrote:
On 2020-12-17 13:30, Johnny Hughes wrote:
Red Hat is going to an open development model for RHEL using CentOS Stream.
will it be something similar hp is doing with clearOS development?
https://www.clearos.com/products/clearos-editions/clearos-7-compare-editions
Well .. the centos stream will be available for free during it's lifetime.
Red Hat is working on more subscription (or even free) models for centos users via: centos-questions@redhat.com
I don't know what those models will be for RHEL .. I don't work on that team inside Red Hat.
Am 17.12.20 um 22:30 schrieb Johnny Hughes:
On 12/17/20 3:14 PM, Leon Fauster via CentOS wrote:
Am 17.12.20 um 21:13 schrieb Johnny Hughes:
On 12/17/20 12:11 PM, Matthew Miller wrote:
On Thu, Dec 17, 2020 at 03:26:50PM +0300, Andrey wrote:
Consider the scenario: a bug or security issue found in both Stream and current RHEL. It was fixed in RHEL in a few days. How fast it will be fixed in Stream? Obviously, it needs some time to port the fix to newer version of package. Days or months?
I think you're pre-supposing that many packages in Stream will be ahead of RHEL. That's not the case. In most situations here, the package version in Stream will be identical to the one in RHEL. In cases where Stream is ahead, in some cases the security fix will be include moving the RHEL package ahead as well to match. In cases where that's too big of a change, the Stream package will still need to be updated so that a regression doesn't happen in the next RHEL minor.
Adding to Matthew's point .. My reply was for things that are different (as that is what you initially asked). Some things will be and others will not be.
But also on the positive side.. Many times though IF a Stream package is newer, the upstream project that maintains the newer code will have already rolled in the change (think a re-base of Gnome, LibreOffice or some other package set). So there may be times when security fixes actually happen first in Stream. That will not be the goal or the default situation, but it will from time to time happen on a re-base of packages.
corresponding to Matthew's point; when the sec fix must be incorporated into stream before the next point release, when will this happen? X day/weeks after RHELx.n RHSA or short before RHELx.n+1?
As I have stated again and again .. all changes (security or not) will be incorporated ASAP. Because, this is the build root for development .. not rolling in things is not an option as OTHER things will be built against what is there. Not having things in the build root renders other pieces invalid. So, things will not be held back.
Red Hat is going to an open development model for RHEL using CentOS Stream.
Sorry if it was stated already. These bits and bytes are all scattered.
BTW. Thank you for your hard work at CentOS! I appreciate this very much.
-
Andrey -
edward -
Johnny Hughes -
Leon Fauster -
Matthew Miller