On Mon, Jan 27, 2025 at 10:12 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
Dne 27. 01. 25 v 15:58 Stephen Gallagher napsal(a):
On Mon, Jan 27, 2025 at 9:40 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
Dne 26. 01. 25 v 16:40 Stephen Gallagher napsal(a):
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.
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@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
_______________________________________________
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
-- _______________________________________________ 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
