On , Abderrahim Kitouni wrote:
Le jeu. 12 sept. 2019 à 15:24, <mcatanz...@gnome.org> a écrit :
On Thu, Sep 12, 2019 at 8:59 AM, Emmanuele Bassi <eba...@gnome.org>
wrote:
> ```
> If you change anything related to the build system:
>
> - dependencies
> - build options
>
> then send a message to release-team@gnome.org.
> ```
Nice, simple, LGTM.
I like this too.
Okay, reworded:
----
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-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 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 depending 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][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
----
Ciao,
Emmanuele.
_______________________________________________
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.