On Mon, Jan 27, 2025 at 10:12 AM Vít Ondruch <vondr...@redhat.com> wrote:
> > Dne 27. 01. 25 v 15:58 Stephen Gallagher napsal(a): > > > > 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. > > > I might have lost a track already, but wasn't one of the concerns build of > package in side-tag, which is in my understanding is similar to not > submitting update in stable versions? > Addressing different personas here. I think we *should* be bothering the maintainers to make sure they don't lose track of updates. But we don't need to push out meaningless updates to end-users either. It's a balancing act. I was only originally concerning myself with Rawhide, really. And I don't think we have enough active users (not automation) there for that to be a real issue. > 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 >
-- _______________________________________________ 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
