Dne 31. 01. 25 v 20:41 Kevin Fenzi napsal(a):
On Fri, Jan 31, 2025 at 02:27:28PM +0100, Vít Ondruch wrote: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 confusionSure, but note if we move the mass rebuild to only rawhide after branching, both will have the right dist-tag, but in rawhide it could mean "this built ok 6 months ago" when we next branch.
Yes. Maybe to you or me. But "this built ok 6 months ago" is not, with all due respect, what our average user thinks. With some luck, our user understands that they are using Fedora 41 and if there is .fc41 package, it is likely compatible with their system. But frankly, I *hope* that most of our users know that they run *Fedora*, without any specifics, because that would mean we are doing good job (now we could argue about Fedora *Workstation* aiming on above average users, namely "developers and creators" who are more tech savvy, but I would like to imagine that Fedora is for masses, using nice GUI, running browser, looking at videos without understanding details).
For me as a Fedora developer, dist tag changes are good indicater that the package built in their recent history. If I see currently .fc41 package, I can understand it (most likely) failed mass rebuild for some reason. But even if the package has .fc42 dist tag, it says only as much as that the package has passed some build since last branching. I don't know how long ago the build was done and if the package passed mass rebuild.
Even if the package built during mass rebuild two weeks ago, it does not say anything about its current state. For that purpose, Koschei does much better job.
In short, the dist tag provides just a hint that the package was build during certain some period of time. It might be beneficial for advanced users. But it is not strictly needed for anything apart of aesthetic.
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."followed up by" meaning in rawhide and in branched both? Or just in branched?
Just in Rawhide. After branching, Fedora is assumed to be in Beta quality and no mass rebuild should be needed.
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.But likewise I don't see benifit in doing it before changes needing mass rebuild have landed.
I don't think there is or should be some deadline for changes landing in Rawhide. IMHO changes should land in Rawhide "anytime" (considering branching is just NTH).
Also this doesn't work for big global changes like rpm payload changes or global packaging changes. Or at least it delays them 6 months.
Was there really some feature which would need to be introduced at any specific time and was not possible to introduce it gradually, over time? I don't think that even the "payload" changes were necessary to be introduced at one point of time. It was just self imposed requirement, so we can make some nice release notes entry. And I would be surprised if even at that time we built 100% packages.
But even if there were 100% success rate needed (which I argue is not needed for most of the changes), then it should be done as soon as such change is ready and likely not 2 weeks before branching.
I don't see what we gain by doing the mass rebuild after branching.
My point is that we can do mass rebuild essentially any time. But doing it two weeks before branching is IMHO the worst possible time, because people are going to land their last second changes. With such timing, mass rebuild brings more harm then benefits.
All 3 of your points are valid. If the FTBFS isn't critical, you can assign the bug and just wait until you want to fix it?
I'd still argue with the reasons of the mass rebuild. Looking at the wiki you have referred to:
https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild#Driving_Features there are three driving features. I'll discuss them one by one: 1) RubyI have certainly not asked for mass rebuild driving the change. So it is surprising to see Ruby on the list. We have done targeted mini mass rebuild. And actually, I know that there are some gaps which arguable mass rebuild can help fill in. E.g. it is not obvious on the first look that vim needs rebuild, because it dynamically loads libruby.so. This is not 100% clear from the runtime dependencies. But using MPB, we know about such cases.
2) Unify usr/bin and /usr/sbinTargeted mini mass rebuild for this feature was done. I am not sure what else should additional mass rebuild bring here
3) GNUToolchainF42I am still not clear what should mass rebuild bring here. MPB can provide the information about potentially broken packages, helping to get them ready prior this change landing in Fedora. Koschei can provide the information about broken packages after GCC lands in Fedora. Assuming there might be some optimizations in new GCC, there might be some nice speed improvements, but these will land sooner (if we pro-actively rebuild some package set with bigger user impact or bigger benefits or even all packages using GCC if we choose to) or later (during regular package lifecycle).
Not sure what else in this change could really require mass rebuild in a way it would be show stopper. The process in general is not documented as far as I can tell. There is no documentation describing how the wiki above is compiled. There is no documentation which would discuss why we even think about mass rebuild and potential benefits. If we target Fedora users or Fedora developers.
IOW there was IMHO no hard requirement for mass rebuild (that means rebuild 100% of packages) for Fedora this cycle.
To sum this up, I can see 3 benefits of mass rebuild: 1) change of dist tag 2) ensuring all packages builds 3) ensuring that all changes with global impact are included But 1) non of this is technically hard requirement unless we say so2) non of this justifies the current schedule and I think there are less busy times when we could do mass rebuild for the reasons stated above.
BTW we were doing mass rebuild as long as I remember (over 14 years). But their history has started prior tools such as Koschei or MPB become available and where packages built by GCC were majority. The times has changed. Making mass rebuild less prominent (and in less busy period) would be next logical step.
Vít
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
