On Mon, Aug 7, 2023 at 5:54 PM Adam Williamson <adamw...@fedoraproject.org> wrote:
> On Mon, 2023-08-07 at 12:24 +0200, Kalev Lember wrote: > > It's also fine to build directly in rawhide if it's just a single > > package update that doesn't depend on anything else. We are still a > > while from Bodhi activation point for F39 so we won't be doing > > mega-updates yet that require everything to be built together in a > > single side tag. > > Well, that's a bit of a wrongly-named milestone these days. > *Everything* goes through Bodhi all the time. The only thing that > changes at the "Bodhi activation point" these days is that the > time/karma requirements kick in. So I'm a bit confused as to why you'd > do a mega-update for branched releases but not for Rawhide? What's the > difference? > Right, so to expand on this a bit: Most GNOME package updates are actually self contained and library ABI is almost always backwards compatible. _Sometimes_ they are not and we need to coordinate stuff to land at the same time, but more often than not modules can be updated one by one. Most of the time the following works fine in rawhide and can be two distinct steps: 1) Update package A to version 1.2 2) Update package B to new version that requires A >= 1.2 This however all breaks apart when we are in a freeze, or when package updates that land in build roots are delayed by a week (after the somewhat badly named "Bodhi Activation Point"). The reason this doesn't work any more then is that the time for packages to land in the base repo is just too long to be able to reasonably do updates separately. Hence, we do mega-updates: a large update that includes both package A version 1.2, and package B that requires the new version of A. This solves the problem with time, so that we can prepare everything in a side tag and get everything through testing together, as a single unit. For rawhide, and branched before the Bodhi Activation Point (which like you pointed out, is a misnomer) this is unnecessary because builds can land in the base repo quickly. Now, why don't we use the same mega-update system for rawhide? I can think of a few reasons: 1) In my opinion, it's best to update packages aggressively, so that we can get them out to testers (and to openQA hands) as quickly as possible. This gives us early feedback and makes it much easier to deal with issues, as they then arise one by one, and we immediately know which package is at fault. 2) Coordination: It's much easier to coordinate package builds with other work happening in rawhide if we can integrate everything quickly into the same repo. Side tags work fine if we don't expect other people to work on the same packages, but rawhide often gets soname bumps in other, non-GNOME packages and they need to be able to get packages rebuilt, without waiting for a long time for GNOME side tags to land. 3) Named side tags (f39-gnome) have certain issues for rawhide (which we talked about on the releng channel not long ago) and while I like having them around so it's easier to coordinate with all the people working on GNOME packaging when we need to land things as a single unit, it doesn't scale very well (needs work from my side to merge etc). Because of that, I think it's best to land builds that are self-contained separately in rawhide. A piece of a puzzle that made it all possible not long ago is the activation of openQA gating that makes it possible to test updates individually. Before that, a human could only run so many integration tests and it realistically only worked to test all of the updates together. Now with openQA, we can be reasonably sure that an individual update doesn't regress the base OS. Now, for Branched after the Bodhi Activation Point, up until the GA release (at this point, we should be ABI stable so packages can land separately again), I think it makes a lot of sense to do mega-updates all the time: 1) We get a way to land a GNOME release all as a single unit if we need to pull it through a freeze. Once we've started rebuilding packages against new versions of libraries then the whole unit becomes pretty much inseparable. 2) We can test the whole thing together (+-karma) - for humans, it doesn't scale to test updates separately, there's just too many combinations At this point, I got tired of typing :) What do you think, does it make sense? -- Kalev
_______________________________________________ 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
