On Mon, Feb 10, 2025 at 1:56 PM Kevin Fenzi <ke...@scrye.com> wrote: > > On Tue, Feb 04, 2025 at 06:41:07PM +0100, Vít Ondruch wrote: > > I started replying to everything, but then I realized it's probibly not > worth me doing so. :) > > ...snip... > > > 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 so > > > > 2) 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. > > ok. Fair enough. > > > 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. > > I'd really love to hear any other folks chiming in here instead of us > going back and forth. > > I think you do make some good points. I like the idea of targeting/mini > mass rebuilds if packages can be identified. Perhaps we could move the > mass rebuild to another time, but I would need to ponder on that more. > > Thanks for the discussion!
Targeted mini mass rebuilds are not easy to do with our current tooling. And depending on how extensive the package set is, it can be pretty grueling to pull off by hand (which is what people have to generally do). Unfortunately, I think it still makes sense to include a mass build every cycle where it is right now as long as the global infrastructure is unable to do automated targeted rebuilds. Particularly, things like Python and GCC do necessitate it because the reverse dependency graph covers more than half of the distribution. Build flag changes also tend to roll up in toolchain changes, so it's important to capture that throughout the distribution. However, we definitely need to push back the integration date to make sure people have more time. A big part of the problem we had here was a combination of not broadcasting the C standard change and its implications and not having a big enough window for the toolchain team to fix most of the really crappy bugs. In itself, the mass build is *fine* given the limitations of our infrastructure. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
