On Sat, Jan 25, 2025 at 12:24 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
