the release team would like to kindly ask **all** GNOME maintainers to send an email to release-team gnome org
... every time their project(s) introduce a new dependency, or update the version requirement.
Should we extend this to tweaking/adding/removing meson options? Cheers, Jordan ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, September 11, 2019 3:48 PM, Emmanuele Bassi <ebassi gnome org> wrote:
[ This is the draft of the email I'm planning to send to desktop-devel, and publish on Discourse. Feedback is very much welcome. ]
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. The announcement is especially important for dependencies hosted outside of gitlab.gnome.org.
How does an announcement look like?
------------------------------------
A simple email with:
- the name of the dependency
- the minimum required version of the dependency
- 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
sent to release-team gnome org will suffice.
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 new dependency is introduced, or if the minimum requirement gets updated, the build will fail until the recipe is updated; and, in the case of new dependencies, until a new recipe 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
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.
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 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
release-team gnome org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Attachment:
publickey - jordan@alatiera.com - 0x0BDAD30B.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature