On Sun, Jan 26, 2025 at 4:40 PM Stephen Gallagher <sgall...@redhat.com> wrote: > > > > 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.
I agree. I don't think anything should be pushed into dist-git that isn't built for rawhide for like ... maybe > 3 weeks (or built in side-tags and not submitted to bodhi in a similar time-frame). Mass changes like the SPDX migration shouldn't be a special case here - after all, the spec file changes will never end up in repositories if they're pushed but never built. Fabio -- _______________________________________________ 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
