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. -- 真実はいつも一つ！/ Always, there's only one truth!