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.