These are my thoughts why we do mass rebuild:
1) One user visible benefit is having consistent dist tag.2) Global performance optimizations or generally global configuration. Ok I got that, but there are probably better times to do some minimass rebuild on more targeted package set.
3) We also want to make sure that everything still builds (despite having Koschei). This is good goal. But still, our users don't generally care about this.
4) Having everything rebuild by GCC 15? That on itself is not a goal IMHO. Making sure everything works with GCC 15 is good goal, but that is problem for developers, not for users (we can argue if there are CVEs, this might become problem, but this is not reflected in the schedule anyway). What percent of packages are actually using GCC these days? My gut guess is that it is not majority anymore. Having targeted minimass rebuild would also be much better for this purpose. Not mentioning that it seems that this discussion was opened due to mass rebuild being obstacle for the tool chain, instead of help 🤷
So why won't we postpone the mass rebuild after branching? That would IMHO provide the most user visible change and that is the change of dist tag. And it would provide the information about the general state of packages.
Vít [1] https://fedoraproject.org/wiki/Fedora_41_Mass_Rebuild Dne 27. 01. 25 v 19:03 Fabio Valentini napsal(a):
Hi all, For reference, this has been discussed at the last FPC meeting: https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2025-01-23/fpc.2025-01-23-17.00.log.html And I filed a corresponding RFC with FESCo here: https://pagure.io/fesco/issue/3347 In an effort to avoid the large amount of breakage during the mass rebuild that happened with GCC 15 and Go 1.24 landing only *hours* before it was started, we suggested the following: "Major toolchain upgrades must land at least 7 days before the scheduled start of the mass rebuild." This would mean either major toolchain updates would need to be pushed slightly earlier, or the mass rebuild is started slightly later, plus / minus a few days. A proposal to move the January mass rebuild back by two entire weeks had previously been rejected by FESCo, mostly because it would result in the mass rebuild (and its fallout) happening during FOSDEM. Making sure major toolchain updates are in place at least one week before the start of the mass rebuild should give maintainers more time to deal with potential breakage and / or give compiler maintainers more time to fix regressions that are only found after the update lands. Due to the way how release schedules line up, this additional "checkpoint" would mostly affect GCC and golang, but potentially also other major toolchains - though LLVM will likely continue to need an exception to allow landing the major update "very late" - because the LLVM release schedule doesn't line up well with the Fedora release schedule. There have been some comments on the FESCo ticket, but it would probably be better to have a discussion on the mailing list, instead. Fabio
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
