On Fri, Aug 20, 2021 at 4:09 PM Josh Boyer <jwboyer at redhat.com> wrote: > > On Fri, Aug 20, 2021 at 3:36 PM Neal Gompa <ngompa13 at gmail.com> 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 > > You have clearly never worked on making a change to a RHEL package :). > I will promise you that there are already a significant number of > steps that developers must do to even get to the point where they can > file an MR. Putting more process and tooling and hurdles in their way > before the code even gets into RHEL is absolutely a resource problem > and I am not going to sign them up to do that. If anything, we're > trying to simplify even though many will tell you it doesn't look like > that. > > I know you meant that with good intention, but it's easy to read it as > "there's no resourcing problem because someone else has to do the > work." > I certainly have made changes to RHEL packages. My name exists in changelogs and commits in enough packages in RHEL and CentOS Stream that I think that would be an unfair characterization. :) I'm aware of most of the steps for making package changes in RHEL, and I already am aware that packagers for RHEL have to go through the effort of declaring what an update is, what it's for, and whether it requires relogin/reboot to fully apply. These are the core properties that are defined in updateinfo. Defining them to push a build in CentOS Stream is something that I don't think is an unreasonable ask. It's the same thing we ask community folks in Fedora to do, after all. > > 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. > > > > The idea is not new: I've talked to the CentOS project folks about it > > many times in the past. They get *extremely* uncomfortable and tell me > > that they can't do it for various reasons even though they want to. > > It's one of the biggest complaints everyone has about the project. > > It's made worse by the fact that none of the ecosystem tooling for > > updates works in any useful manner without updateinfo. RPM changelogs > > are no substitute because no automation works with that. You know that > > as well as everyone else here. > > Producing that information isn't only about tooling, and the fact that > people would immediately rely on it for automation makes it difficult > to suggest anyone else doing it on the side is a viable solution. If > it's wrong, that has bad consequences. I'd certainly be against it > under the project umbrella if it wasn't part of the official delivery > anyway. > > I still question the utility of it though. It's a continuous delivery > model. You have to update. Want to know if you have all available > bug fixes? Update. If your bug isn't fixed, it doesn't change the > fact that you have all *available* bug fixes. There are no batches or > releases. It's called Stream for a reason. > That doesn't mean I shouldn't have the ability to configure dnf-automatic to apply all updates automatically that don't require relogin and reboot and then have it email me to notify me for updates that *do* require that so I can schedule time to actually go and apply it. -- 真実はいつも一つ！/ Always, there's only one truth!