(brief summary of building GNOME for Fedora) |
(add some packages handled by others) |
||
Line 9: | Line 9: | ||
== Submitting (mega)updates == | == Submitting (mega)updates == | ||
The builds in the side tag are not automatically migrated to the real branched tag, so they must manually be either tagged into the appropriate branch (before any freezes), or tagged into the appropriate -candidate tag and then added to a bodhi update. It is best to submit a bodhi update as a large group of packages (a megaupdate), to make it easy for testers and packagers alike. Bear in mind freeze deadlines when creating updates, as updates will only move into the main repository during freezes if there are freeze exception bugs associated with them (and that possibility is somewhat likely with something as large and complex as all of GNOME). If a package is not built against the side tag, but is needed as a dependency, it can be tagged in manually. | The builds in the side tag are not automatically migrated to the real branched tag, so they must manually be either tagged into the appropriate branch (before any freezes), or tagged into the appropriate -candidate tag and then added to a bodhi update. It is best to submit a bodhi update as a large group of packages (a megaupdate), to make it easy for testers and packagers alike. Bear in mind freeze deadlines when creating updates, as updates will only move into the main repository during freezes if there are freeze exception bugs associated with them (and that possibility is somewhat likely with something as large and complex as all of GNOME). If a package is not built against the side tag, but is needed as a dependency, it can be tagged in manually. | ||
== Packages to handle specially == | |||
* gnome-shell and mutter are handled by Florian, so coordinate with him if pushing patches or other fixes. This is especially true as generally gnome-shell will depend on the latest version of mutter, so both packages will often have to be updated in lockstep | |||
* evolution, evolution-data-server, gnome-software are handled by Milan | |||
* gjs is often updated when spidermonkey is updated, as it changes ABI frequently, so care should be given that gjs and spidermonkey are placed into updates together | |||
* gdm and accountsservice are handled by Ray |
Latest revision as of 13:27, 15 January 2024
In Fedora, the GNOME SIG handles most GNOME packaging tasks, and has admin or commit rights to the packages which are a priority for GNOME.
Tools for automation
For each major GNOME release, a person will be in charge of shepherding the builds into Fedora, and coordinating with other package maintainers to make sure that happens with the minimum of fuss. Generally, this will be Kalev or David, but anyone is welcome to volunteer or help out with builds. We use the mclazy tool to partially automate upstream version checking and package version bumping, but more complex patching, dependency changes, etc. will need manual intervention.
Which branches to build for
Development versions of GNOME should be built in Rawhide first. Fedora generally branches off a new version at some late point in the GNOME development cycle, and so at that point, builds should first go into Rawhide, and then the branched version. To help with this a side tag is generally set up, which is named fxx-gnome, where xx is the version of the new Fedora branch. Builds in the side tag are in their own buildroot (which inherits the buildroot of the branched version), and so it is easy to update libraries and other dependencies without affecting the rest of Fedora, and without using buildroot overrides.
Submitting (mega)updates
The builds in the side tag are not automatically migrated to the real branched tag, so they must manually be either tagged into the appropriate branch (before any freezes), or tagged into the appropriate -candidate tag and then added to a bodhi update. It is best to submit a bodhi update as a large group of packages (a megaupdate), to make it easy for testers and packagers alike. Bear in mind freeze deadlines when creating updates, as updates will only move into the main repository during freezes if there are freeze exception bugs associated with them (and that possibility is somewhat likely with something as large and complex as all of GNOME). If a package is not built against the side tag, but is needed as a dependency, it can be tagged in manually.
Packages to handle specially
- gnome-shell and mutter are handled by Florian, so coordinate with him if pushing patches or other fixes. This is especially true as generally gnome-shell will depend on the latest version of mutter, so both packages will often have to be updated in lockstep
- evolution, evolution-data-server, gnome-software are handled by Milan
- gjs is often updated when spidermonkey is updated, as it changes ABI frequently, so care should be given that gjs and spidermonkey are placed into updates together
- gdm and accountsservice are handled by Ray