On Mon, Sep 12, 2022 at 10:22 AM Leon Fauster via CentOS-devel < centos-devel at centos.org> wrote: > Am 12.09.22 um 16:47 schrieb Troy Dawson: > > > > > > On Sun, Sep 11, 2022 at 2:05 AM Phil Perry <pperry at elrepo.org > > <mailto:pperry at elrepo.org>> wrote: > > > > On 11/09/2022 08:41, Branislav Náter wrote: > > > Hi, > > > > > > > > > On Sat, Sep 10, 2022 at 8:46 PM Leon Fauster via CentOS-devel > > > <centos-devel at centos.org <mailto:centos-devel at centos.org> > > <mailto:centos-devel at centos.org <mailto:centos-devel at centos.org>>> > > wrote: > > > > > > I wonder about the current firefox build 91.13.0-1.el9? Its > > not on the > > > mirrors (comp 20220829) nor in the last prod compose > > (20220909) / both > > > lists firefox-91.11.0-2.el9 ... Thanks. > > > > > > > > > For inclusion in the compose, it has to pass testing. Testing is > > still > > > in progress. > > > > > > > > > > I'm just trying to understand how it can still be in testing for > Stream > > when it has clearly passed testing and been released to RHEL? I > thought > > Stream sat 'upstream' of RHEL? > > > > What extra testing is performed for packages in Stream that is not > > performed for the same packages in RHEL? What tests are failing? > Should > > we be concerned as RHEL users that we are not receiving the full > > testing > > experience? > > > > > > So people know the sequence of events. > > > > firefox-91.13.0-1.el9_0 was built in RHEL 9.0 on 2022-08-18 > > - The build passed all of it's gating tests. > > - This was built on a RHEL 9.0 buildroot, and tested on a RHEL 9.0 > buildroot > > - This got pushed to RHEL 9.0 only > > > > firefox-91.13.0-1.el9 was built on CentOS Stream 9 and RHEL 9.1 on > > 2022-08-25 > > - This build did not pass it's gating tests - it still hasn't > > - This was built on a RHEL 9.1 buildroot, and tested on a RHEL 9.1 > buildroot > > - As far as I can tell, it's got the same tests. It's possible that one > > or more of the tests went from "warn when it fails" to "fail when it > > fails", but it looks like the tests are the same. > > - It's also possible that something changed in RHEL 9.1 that is causing > > the tests to fail. > > - I'm not on the firefox team, I'm just looking at the gating system, > > and to be honest, when I look beyond the "passed" - "failed" parts and > > into the results, I get lost. > > > > From everything I can see, this delay wasn't the result of an embargo, > > simply tests not passing. > > > > > I had the understanding that those gates are responsible to sync between > RHEL/CENTOS build pipelines? Especially for the major version 9 this > should be the state or do I misunderstand the workflow? > > -- > Leon > Since I don't exactly know what you are picturing as a workflow, I'll step through an average package update on RHEL9. 1 - maintainer (or others) create a merge request into CentOS Stream 9 gitlab area. 2 - the merge request is gated and tested before being merged. 3 - When that merge request gets merged in the Stream 9 gitlab area, it is also synced over to the internal Brew dist-git area. 4 - The maintainer starts the build in CentOS Stream 9. 5 - When that happens, a build starts on the internal Brew systems. 6 - When both builds finish, they are both gated. The testing only happens internally on the Brew build. 7 - When the internal testing passes successfully, then both RHEL and CS builds are moved on. 8 - Internally, an errata is made, or an errata is updated with the new build, and both packages move to -pending. 9 - Composes are created out of the -pending packages. Early on there was talk about putting gating between CS and RHEL, but that would make the build repo's different, and eventually the CentOS Stream and RHEL builds would diverge. I've simplified the steps some, and it's possible I didn't explain everything correctly. So if you need me (or others) to explain or expand on some of the steps, let me know. Troy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20220912/785a277a/attachment-0002.html>