Re: Announcement of new dependencies for GNOME modules

[Emmanuele Bassi <ebassi gnome org>]

On , Abderrahim Kitouni wrote:
> Le jeu. 12 sept. 2019 à 15:24, <mcatanzaro gnome org> a écrit :
> > On Thu, Sep 12, 2019 at 8:59 AM, Emmanuele Bassi <ebassi 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-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 depending 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

----

Ciao,
 Emmanuele.