On 1/25/21 8:56 PM, Mike McGrath wrote: > ... the code should already be available via CentOS Stream. To put it > another way, the current plan of record is - If you ever find a RHEL > binary, and cannot find the corresponding source code in the CentOS > Stream gitlab instance, that means we've messed something up along the > way because it was one of the explicit goals for CentOS Stream. It > might be released in RHEL first with a bit of delay (we're talking hours > or a day or two not weeks), like with a 0-day CVE. But generally, it > should already be in CentOS Stream well before it's in RHEL. > > I hope that's clearer. Worst case, the rebuilders you're talking about > will have to get to know our gitlab layouts, but all the code will be there. > > For emphasis: There are no plans to stop making RHEL code available to > the public at this time. It will just take a different route to get > there than it has under RHEL8/CentOS8 and before. Thanks for the quick reply. If I understand correctly, the idea is to move from RHEL point releases to a rolling distro inside a major point release, powered by CI/CD automated tests to ensure that any point in time, any commit, will be ready to ship (or at least tagged commits, which I guess official RHEL packages would be built from)? Then rebuilds would only have to checkout a specific tag and rebuild? As long as point releases exist, I think it would make sense to run RHEL in production and CentOS Stream on testing machines, to get advanced notice if something is going to break in the next point release and be able to file bugs. With a rolling model, this time difference would become much smaller. Would there still be an equivalent of EUS is such a rolling model, allowing an organization to get security updates until bugs in backported features are sorted out?