[CentOS-devel] Is there any way to follow errata for Stream 8?

On 8/20/21 4:31 PM, Neal Gompa wrote:
> On Fri, Aug 20, 2021 at 4:19 PM Brian Stinson <bstinson at redhat.com> wrote:
>>
>>
>>
>> On 8/20/21 2:35 PM, Neal Gompa wrote:
>>> On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer <jwboyer at redhat.com> wrote:
>>>>
>>>> On Fri, Aug 20, 2021 at 1:37 PM Carl George <carl at redhat.com> wrote:
>>>>>
>>>>> On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa <ngompa13 at gmail.com> wrote:
>>>>>>
>>>>>> On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes <johnny at centos.org> wrote:
>>>>>>>
>>>>>>> On 8/19/21 11:21 PM, John R. Dennison wrote:
>>>>>>>> On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
>>>>>>>>> Even emails like I see for for CentOS 7 would be ok.
>>>>>>>>
>>>>>>>> Considering that people have had nearly 2 years to get such notices out
>>>>>>>> for 8 and it's still not happened I wouldn't hold my breath if I were
>>>>>>>> you.
>>>>>>>>
>>>>>>>
>>>>>>> I would provide the information if i could, it is not easy to do because
>>>>>>> of modularity.
>>>>>>>
>>>>>>> The thing that builds el8 modules is called MBS .. if you look at MBS
>>>>>>> operations, one of the things that gets generated as part of the
>>>>>>> filename.  Here is an example:
>>>>>>>
>>>>>>> https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
>>>>>>>
>>>>>>> Part of the file name is dynamic, created by MBS at build time.  For
>>>>>>> example, one of the Source RPM filenames generated is:
>>>>>>>
>>>>>>> runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
>>>>>>>
>>>>>>> That is not it's filename in RHEL8.  In RHEL 8 .. the filename is:
>>>>>>>
>>>>>>> runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
>>>>>>>
>>>>>>> There is no easy way to figure out the file names that match up between
>>>>>>> the two systems.  I took me 15 minutes to figure out that one filename,
>>>>>>> this does not scale.
>>>>>>
>>>>>> Everything prior to ".module" should be unique, identifiable, and
>>>>>> identical between RHEL and CentOS. MBS whacks %dist to add MBS
>>>>>
>>>>> Not exactly.  Sometimes RHEL maintainers add digits after %dist, which
>>>>> results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1.  It's
>>>>> not impossible to parse, but it's much more complicated that just
>>>>> ignoring everything after ".module".
>>>>>
>>>>>> information at the end. So there is some mapping. Additionally, when
>>>>>> the RPMs are imported from RHEL into CentOS, the original NVR is
>>>>>> present as a tag. Ignoring transmodrifier remapping modulemd commits
>>>>>> between RHEL and CentOS, you have enough baseline references to be
>>>>>> able to connect the dots because the RHEL dist-git shorthash is
>>>>>> present in the import tag, which would exist in the imported modulemd
>>>>>> before transmodification.
>>>>>>
>>>>>> That process could be automated, but I was never particularly
>>>>>> motivated to do it because of the historical attitude around providing
>>>>>> errata for CentOS users like Fedora users get.
>>>>>
>>>>> I'm not aware of any policy against allowing this in the project.  If
>>>>> there is I hope board members will speak up and clarify that.  I
>>>>> suspect it's more of a resource thing than anything.
>>>>
>>>> I think lack of awareness of a publicly documented policy against
>>>> allowing this in the project is likely true, but also irrelevant.  We
>>>> don't have a policy against allowing a FreeBSD kernel or using
>>>> Ubuntu's version of gcc, yet we wouldn't do those.  In the absence of
>>>> meticulously detailed bylaws, we have historical precedent setting
>>>> defacto policy.  I don't expect this to change.
>>>>
>>>> That being said, an update metadata mechanism for CentOS Stream is
>>>> certainly hampered by resource constraints both in terms of tooling
>>>> and in terms of the impact on the people developing the OS through the
>>>> CentOS Stream project.  For a continuously developed and continuously
>>>> delivered OS, we expect a large amount of churn on a day to day basis.
>>>> Updates are a regular occurence, and they're important either because
>>>> of fixes or because of new features.  Changes are documented in MRs,
>>>> RPM changelogs, and referenced bugs for those interested.
>>>>
>>>
>>> It's always been possible to have updateinfo generated as build
>>> submissions go through. That's literally how it's done in Fedora with
>>> Bodhi.
>>>
>>> It's not that much of a stretch to say "deploy Bodhi, make voting
>>> advisory or turn it off, and have builds submitted through it with the
>>> right information and auto-release based on gating checks". That
>>> structured data can be pulled in and used for Red Hat update
>>> advisories internally too, which simplifies the pipeline to validate
>>> and release updates. Or if you have a beef against Bodhi, then why not
>>> use the tooling Scientific Linux created to make updateinfo? Troy and
>>> Pat are very familiar with it, and it's publicly available:
>>> https://pagure.io/python-Updateinfo
>>>
>>> Okay, let's say we can't do it for CentOS Stream 8 because of resource
>>> constraints. Well then, what about CentOS Stream 9, where the RHEL
>>> developers themselves are submitting the builds? There's no logical
>>> resourcing problem there. Deploy Bodhi for update submissions and tie
>>> the gating into the auto-release criteria. The Fedora CI folks were
>>> already doing that for Fedora Rawhide, so it's no stretch to have it
>>> for CentOS Stream too.
>>
>> It's not Bodhi vs. another tool in this case. The reason we don't deploy
>> an update manager in Stream is that we want to avoid an artificial gate
>> before the RHEL process begins. In practice, CentOS Stream builds are
>> promoted through the workflow in lockstep with their RHEL counterparts.
>> This means CentOS Stream builds are subject to the fate of the RHEL
>> gating results and other bits of paperwork and process that maintainers
>> must go through to release a build into RHEL proper. If any of that RHEL
>> process leads to a NAK we want to NAK a build in Stream too and we'd be
>> overriding any pre-prepared updates in a hypothetical Stream update
>> manager anyways.
>>
> 
> Maybe I said this wrong, but I think that this use-case is something
> that Bodhi supports fine. Configuring Bodhi to respond to RHEL gating
> and only push when RHEL pushes is something that Bodhi could do by
> listening to whatever pushes RHEL builds. Having the RHEL NAK block a
> CentOS Stream build seems reasonable, just as the other way would too.
> You should be able to enforce that they land in tandem. Not reusing
> Bodhi for this seems like a bad idea, especially after all the effort
> to implement this capability in there for Fedora CI on Rawhide builds.
> 
> 
> 

The thing that pushes RHEL builds is already the thing that influences
when Stream builds move along in the workflow.

Let's break this down by use-case, though:

"I want to comment on a build before it makes it into RHEL" => Use the
open bugzilla or comment on the open merge request

"I want to try out a build before it makes it on the mirrors" => Pull
from the buildsystem or from the development composes

"I want to test a package before a build is made" => We're working on
expanding pre-merge and post-merge CI. Note: this is a much better place
to influence and provide feedback before a build makes it into the
process than an update/errata

Running an update manager in Stream would be extra work, when we want to
encourage the use-cases to be addressed elsewhere anyways.

--Brian