Re: Maintainers should announce build-related changes in their modules

[Michael Gratton]

On Thu, 12 Sep, 2019 at 22:39, Philip Withnall  
wrote:

On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote:
On Thu, 12 Sep, 2019 at 19:08, Philip Withnall 
 wrote:
That sounds like something people are going to forget to do. Would 
it be possible to use computers to automate this?


It's software: anything is possible.

As to whether we can automate this **right now**, the answer is: no.


It's a shame that build deps can't be picked up automatically from the 
meson build config, where it's already specified.


What about requiring modules include a buildstream config fragment with 
a well-known name in their repos, much like how DOAP files are 
required, which then gets pulled in by the release team's CI?


That would also enable having a standard Gitlab CI script for the 
per-module CI which also pulls the config in and does a build based on 
that (much like the one that already exists for for building Flatpak 
manifest), and hence also act as a reminder for maintainers to keep it 
up to date when it fails.


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Maintainers should announce build-related changes in their modules

[Philip Withnall]

On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote:
> On Thu, 12 Sep, 2019 at 19:08, Philip Withnall <
> phi...@tecnocode.co.uk> wrote:
> > That sounds like something people are going to forget to do. Would
> > it be possible to use computers to automate this?
> 
> It's software: anything is possible.
> 
> As to whether we can automate this **right now**, the answer is: no.
> 
> I'm not going to block on a feature that may or may not appear in
> Gitlab's enterprise edition and then may or may not be backported to
> the community edition we have. Of course, enterprising hackers are
> strongly encouraged to work on that.

The link to the GitLab EE issue was illustrative, not definitive. If it
solves the problem, a cronjob which polls every module’s `/meson.build`
and `/meson_options.txt` files every 30 minutes and uses sendmail to
send you an e-mail about changes would work.

> From my perspective, I don't think is much to ask to the community of
> GNOME maintainers to help us on the release team (and all the people
> that build GNOME components) in ensuring their projects actually
> build instead of deploying hopes and prayers to users.

I don’t think anyone is going to begrudge you their time, it’s just the
practicality of having ~30 humans remember to send an e-mail to a list
every time they (infrequently and rarely) touch a particular part of
their code base.

I will endeavour to remember to do so, but I can pretty much guarantee
I’ll forget at some point. I apologise in advance.

Philip
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Maintainers should announce build-related changes in their modules

[Emmanuele Bassi]

On Thu, 12 Sep, 2019 at 19:08, Philip Withnall  
wrote:
That sounds like something people are going to forget to do. Would it 
be possible to use computers to automate this?


It's software: anything is possible.

As to whether we can automate this **right now**, the answer is: no.

I'm not going to block on a feature that may or may not appear in 
Gitlab's enterprise edition and then may or may not be backported to 
the community edition we have. Of course, enterprising hackers are 
strongly encouraged to work on that.


From my perspective, I don't think is much to ask to the community of 
GNOME maintainers to help us on the release team (and all the people 
that build GNOME components) in ensuring their projects actually build 
instead of deploying hopes and prayers to users.


Ciao,
Emmanuele.



___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Maintainers should announce build-related changes in their modules

[Philip Withnall]

On Thu, 2019-09-12 at 18:54 +0100, Emmanuele Bassi via desktop-devel-
list wrote:
> 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).

That sounds like something people are going to forget to do. Would it
be possible to use computers to automate this?

For example, https://gitlab.com/gitlab-org/gitlab-ee/issues/1817

Philip
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Maintainers should announce build-related changes in their modules

[Emmanuele Bassi via release-team]

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 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][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]: 
[2]: 
W: https://www.bassi.io

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[Emmanuele Bassi]

On , Abderrahim Kitouni wrote:

Le jeu. 12 sept. 2019 à 15:24,  a écrit :


On Thu, Sep 12, 2019 at 8:59 AM, Emmanuele Bassi 
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.

Re: Announcement of new dependencies for GNOME modules

[Abderrahim Kitouni]

Le jeu. 12 sept. 2019 à 15:24,  a écrit :
>
> On Thu, Sep 12, 2019 at 8:59 AM, Emmanuele Bassi 
> 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.

Abderrahim
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[mcatanzaro]

On Thu, Sep 12, 2019 at 8:59 AM, Emmanuele Bassi  
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.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[Emmanuele Bassi]

On , mcatanz...@gnome.org wrote:

On Wed, Sep 11, 2019 at 11:04 AM, Jordan Petridis via release-team
 wrote:

Should we extend this to tweaking/adding/removing meson options?


Good point, yes.


Mmmh, I don't want to complicate the messaging too much by conflating 
two separate contexts, unless we want to change it to something like:


```
If you change anything related to the build system:

 - dependencies
 - build options

then send a message to release-team@gnome.org.
```

Alternatively, I can send an additional request of notification for 
build options.


Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.