On Mon, Jan 27, 2025 at 9:40 AM Vít Ondruch <vondr...@redhat.com> wrote:
> > Dne 26. 01. 25 v 16:40 Stephen Gallagher napsal(a): > > > > 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. > > > I would agree with your statement if I was considering this just from > mass-rebuild perspective. But considering usage of those packages, I > believe that we should always consider the amount of updates. > > If I ignore that am Rawhide user consuming such changes, updated package > in Rawhide also means that maybe others mock caches will become obsolete. > > So, in the case of Branched/Stable Fedora, we can always opt not to submit a Bodhi update to avoid bugging people. With Rawhide's automated updates, that does indeed lead to more churn, but I'd argue that this is probably not a major issue. The majority of Rawhide usage is likely to be in CI systems rather than end-user systems (Kevin, myself and other insane people who run Rawhide on our primary machines notwithstanding). So I don't think the impact would be terrible. > 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 >
-- _______________________________________________ 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
