Dne 30. 01. 25 v 23:33 Kevin Fenzi napsal(a):
On Wed, Jan 29, 2025 at 10:01:09AM +0100, Vít Ondruch wrote:Thanks for clarifying. Of course one reason for mass rebuild can be that we are not able to properly identify the package set for more targeted mini mass rebuild. But IMHO, having just the Copr build to identify the problematic packages is good enough. If we want more, e.g. if new GCC brings some performance optimizations, rebuilding just the 5001 specifically for this occasion and the rest done later by mass rebuild e.g. after branching, that would be still fine. If we want the rebuild due to e.g. glibc changes, we sill can come up with more targeted package set.Right, so you are advocating for mass rebuilds to always be targeted to only the needed subset?
I am advocating for mass-rebuild as we do (i.e. to try to build everything) to be done after stable branch is branched off. For this cycle, the F42 is going to be branched on Tue 2025-02-04, so some time after that (week, month, ...), we would do Rawhide mass rebuild. This would serve the following three purposes:
1) Make sure all packages have fcNN+1 (fc43) dist tag. This can reduce user confusion
2) Make sure that if there were some changes and the targeted mini mass rebuild missed some packages for some reason, such changes are really applied
3) Make sure everything builds. In connection with the 1st point, fcNN tag would make such packages stand out. However, we still have different means to discover something is FTBFS, so this is not that important.
All other changes being it GCC or Ruby or sbin or whatever else would be followed up by targetted mini mass rebuild (possibly only looking to identify the FTBFS). We do this anyway.
Most of the FTBFS are not critical, most of the possible optimizations are not critical (they will be applied sooner or later). And we have the numbers. For F41, there were 568 failed builds at the time of branching [1] and it did not make any serious troubles in global scale. F42 [2] so far does not look any better.
I don't see any benefit doing mass rebuild this late in the cycle. If I am not mistaken, historically some mass rebuild issues resulted in delayed Fedora release. And it makes quite hard to adjust the schedule if needed.
Vít [1] https://kojipkgs.fedoraproject.org/mass-rebuild/f41-failures.html [2] https://kojipkgs.fedoraproject.org/mass-rebuild/f42-failures.html
I guess I think thats pretty nice, but I also think it could mean a lot of work for releng if they have to identify those packages. Perhaps we could move to requiring change owners to identify all packages they want to have rebuilt? Of course we also have had cases were we did want to actually rebuild everything (rpm payload changes, etc). kevin
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
