On Fri, Aug 20, 2021 at 4:09 PM Josh Boyer <jwboyer@redhat.com> wrote:
>
> On Fri, Aug 20, 2021 at 3:36 PM Neal Gompa <ngompa13@gmail.com> wrote:
> >
> > On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer <jwboyer@redhat.com> wrote:
> > >
> > > On Fri, Aug 20, 2021 at 1:37 PM Carl George <carl@redhat.com> wrote:
> > > >
> > > > On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa <ngompa13@gmail.com> wrote:
> > > > >
> > > > > On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes <johnny@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.