On Mon, Jan 25, 2021 at 5:36 PM Leon Fauster via CentOS-devel <centos-devel at centos.org> wrote: > > Am 25.01.21 um 20:56 schrieb Mike McGrath: > > > > > > On Mon, Jan 25, 2021 at 1:03 PM Laurențiu Păncescu > > <lpancescu at centosproject.org <mailto:lpancescu at centosproject.org>> wrote: > > > > On 1/25/21 7:29 PM, Mike McGrath wrote: > > > A fair question. I've been in a few discussions related to this > > > internally and there are no plans to make changes for RHEL8 (IE: us > > > sending our debranded(ish) code to the centos git instance). I > > could > > > imagine scenarios where that gets moved to gitlab. But generally > > how we > > > push will remain the duration of RHEL8 - we just won't be > > building it > > > into CentOS. Don't take this to mean it's a guarantee or that > > Red Hat > > > promised or whatever. I'm just saying that at the moment we've > > > discussed it, no one is currently advocating for us to stop > > releasing > > > RHEL8 code in the way we do, and so we have no plans on changes > > there at > > > this time. > > > > Excuse me, perhaps I'm reading too much into your words, just for my > > own > > understanding: does this mean it's not clear if Red Hat will continue > > forever to release the sources for RHEL publicly, and perhaps only > > provide them to their customers, at some point in the future? I'm > > thinking more from perspective of rebuilds like Alma Linux or Oracle EL > > - they wouldn't have anything to rebuild by themselves anymore. With > > the > > zero-cost RHEL covering the use case of many small companies and > > hobbyists, I imagine this would be possible. > > > > > > This is an area where written text falls flat and a conversation would > > be better but here goes.... > > > > For RHEL9 and forward, I suspect we won't be doing a RHEL release, and > > then releasing that code as we do today because..... > > > > ... 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. > > > > > Without wanting to imply anything, but when I read between the lines: > This sounds that the next major RHEL releases will not provide sources > in a way, that allows someone to identify the current snapshot or point > in time of a RHEL release. That is exactly what people are complaining > about CentOS Stream and next minor release. So, everything (rpm > artifacts) are then on "upstream" (gitlab/rolling dev) and no more > "downstream" side (ftp:10yearsago, git:today). Do I misread this? (as > you stated, a multi-modal conversation would be more appropriate) > I think he's saying is that he's not sure yet how this will work out, but he's at least committing to everything existing in CentOS Stream Git trees at some point before release to RHEL, unless someone goofs up for some reason. Given that Fedora 34 hasn't even been branched yet for Red Hat to start branching for CentOS Stream 9, I think that's about as concrete of a response as we're going to get for now. -- 真実はいつも一つ！/ Always, there's only one truth!