On Sun, 26 Jan 2025 at 13:26, Björn Persson <Bjorn@rombobjörn.se> wrote:
Fabio Valentini wrote:
> On Sun, Jan 26, 2025 at 4:40 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
> > 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.
If I correct a typo in a comment, I should bump the release and cause
churn on build servers and mirrors, even though nothing at all changes
in the binary package?
I am going to say yes because I have seen enough 'I only was fixing a comment' bug fixes which either broke the build or found the build was broken for some reason. Those problems can be anything from 'compiler problems' with the fixed comment to 'ohh I pushed a bunch of code I didn't mean to..'
Packages get bumped and rebuilt for many reasons outside of the mass rebuild. One of the reasons for the 'always ready rawhide' in years past was because release engineering or other people were having to scramble during a security update or some other problem fixing packages because they did not build.
Björn Persson
--
_______________________________________________
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
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ 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
