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