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-t...@gnome.org
<mailto:release-t...@gnome.org> (and possibly Cc:
distributor-l...@gnome.org <mailto:distributor-l...@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
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-t...@gnome.org
<mailto:release-t...@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-l...@gnome.org
## Why is this necessary?
GNOME releases are built from [gnome-build-meta] 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] 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,
desktop-devel-list mailing list