[CentOS-devel] First round of RHEL programs announced

Mon Jan 25 23:00:34 UTC 2021
Mike McGrath <mmcgrath at redhat.com>

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>