On Mon, Jan 25, 2021 at 4: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) > > In an unusual turn of events, I actually should have been a tiny bit more ambiguous in my original response :). We haven't decided what to do with RHEL9's source code yet. It may end up at git.centos.org exactly as 8 does today. We're just not that far along in 9 development and those conversations haven't been finalized. I can say though - were I to put myself in a RHEL-9 rebuilders shoes though, best case source is exactly as its are today. Worst case I would have to look through the gitlab repo for specific versions I want as you've described above. -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210125/87b629f8/attachment-0005.html>