On Sat, Jan 25, 2025 at 12:24 PM Miro Hrončok <mhron...@redhat.com> wrote:
> On 24. 01. 25 22:13, Adam Williamson wrote: > > Note that side tags aren't the only issue. Sometimes a maintainer > > commits a bump to git but doesn't build it in a side tag or rawhide, > > for whatever reason. Sometimes a package is*built*, but gated from > > Rawhide by automated tests, but then the mass rebuild effectively > > overrides the gating (we found several cases like this). Just checking > > side tags isn't gonna catch everything. I really think the appropriate > > check is 'was the build most recently tagged into fXX built from the > > current git commit? if not, don't rebuild this package, yell for manual > > intervention'. > > Generally, this sounds like a good idea. > > However, note that is is not uncommon for (proven)packagers to commit > stuff > that will only eventually get built. We might discover that the number of > packages that we yell at for no good reason is too high. > > As an example of a big chnage, I think the SPDX commits were pushed but > not built. > > It's possible that I'm in the minority here, but I honestly don't think anything should be pushed to dist-git unless it's intended to be built more or less immediately. Yes, even changes without an immediate functional impact like the SPDX changes. That said, I agree with Kevin that we should have the compose reports list anything in the compose whose state is "The commit at the HEAD of the `rawhide` branch does not match the commit used for the latest build in Rawhide" and treat that as a bug (ideally, we'd open one automatically) that must be resolved prior to the next mass-rebuild (either by getting a build done or tagging the bug in some way that indicates that it's okay for the mass-rebuild to build it). Anything still on the list when the mass-rebuild is ready to start should be skipped and the bug should be marked as a blocker for Beta (to make sure it gets looked at). Detecting this should be fairly easy, albeit adding a bit to the Koji API load.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
