Maintainers should announce build-related changes in their modules

[Emmanuele Bassi <ebassi gmail com>]

Hi all; the 3.34 release is out of the door, but before we go into the 3.35 development cycle, the release team would like to kindly ask **all** GNOME maintainers to send an email to release-team gnome org (and possibly Cc: distributor-list gnome org) every time their project(s) introduce a new dependency, or update the version requirement of existing dependencies, or change the build options of their project(s). The announcement is especially important for dependencies hosted outside of gitlab.gnome.org. ## How does an announcement look like? A simple email sent to release-team gnome org will suffice. If you added or updated a dependency, please specify: - the name of the dependency - the minimum required version of the dependency - the build options of the dependency your project requires - the source code repository of the dependency and the branch/tag to be used -OR- - the location of the release archive, possibly with the size and SHA256 checksum of the release If you changed a build option: - the name of the old and new build option - whether it's automatically enabled or disabled based on a dependency As a friendly notice to the downstream distributors of GNOME modules, you may also want to Cc: distributor-list gnome org. ## Why is this necessary? GNOME releases are built from [gnome-build-meta][1] recipes; if a build option is changed, a new dependency is introduced, or if a minimum requirement gets updated, the build will fail until the recipe is updated; and, in the case of new dependencies, until a new recipe for the dependency is written and tested. Failed builds block everything: - the CD pipeline that generates the Flatpak run times for CI - the release pipeline - in the future, it'll also block the build of installable VMs for design, QA, and user testing This means that a broken build is going to make the life of everyone else in the project harder. As builds take a lot of time to complete, it might happen that the breakage introduced by a new dependency will go unnoticed for a while; on top of that, it requires the release team to go and hunt down the dependencies repositories, tarballs, or release archives, and figure out the build options your own project depends on. ## I already have to update the CI, I might forget to send an email It's understandable: we do have a large infrastructure, so it might happen that you forget something. Ideally, if you're updating your custom CI, you're also going to have time to send a very short email to a mailing list. ## Can I update gnome-build-meta myself? Of course! Open a [new merge request][2] against gnome-build-meta, and the release team will be happy to review it and merge it. ## Is this mandatory? Currently, we want to be flexible with maintainers, so this requirement is not going to be enforced; this is also why it's an *announcement*. If builds keep breaking during 3.35 because of new/updated dependencies, the release-team might start considering something more binding, like pinning modules to previously released tags/versions; if that proves to be impossible due to module interdependencies, we might very well end up reverting commits in the offending module(s). On behalf of the release team, Emmanuele. [1]: https://gitlab.gnome.org/GNOME/gnome-build-meta [2]: https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests

W: https://www.bassi.io