Re: Reminder: action required when updating dependencies or build options

[Michael Catanzaro <mcatanzaro gnome org>]

On Thu, Jan 14, 2021 at 11:04 am, Philip Withnall 
<philip tecnocode co uk> wrote:
> I don’t know anything about what the release team is doing with all
> these modules, or why, but perhaps rather than the default being 
> “pull
> in all the modules into an OS build and urgently push fixes to the
> modules if something fails”, could the default be “only pull 
> module
> updates into an OS build if they don’t fail”? i.e. Essentially 
> pinning
> each module in the OS build by default, and regularly updating those
> pins via a CI gate.

Hm, in theory it should be *possible*, but probably not so easy to do. 
Remember that it's not always easy to tell which component introduced a 
build failure. E.g. when the gnome-clocks build was failing, the 
solution was to change libgweather, not gnome-clocks itself. So the 
build system would need to be able to individually test changes to 
every module that changed between last successful build and current 
failing build in order to decide which module to hold back. But GNOME 
builds take several hours. So, in practice, this seems hard to do.

> Then individual module maintainers can work at their own pace, and
> updates (e.g. API changes) can land in different modules without
> needing prior consultation with the release team.

Anyway, you can do this today by either (a) editing your .bst element 
to point to a tarball instead of git master (easy), or (b) asking 
release team to do this for you (we don't bite). So it's not a huge 
effort. The hardest part is remembering to change it back to git master 
when you're done making breaking changes. This was a problem with 
gnome-continuous: we regularly had a large number of components pinned 
to older versions because they did not build in combination with 
everything else. Nowadays, we've ironed out such issues and are 
building everything we can from git master, and I think that's for the 
best. That's why I use pinning to a tarball version as the very last 
resort, when the only way I see to quickly fix the build would be to 
revert a large series of commits.

Maybe in retrospect, we could have avoided this issue if libgweather 
was built from tarball instead of git master. But even then, it sure 
seems like making a mountain out of a molehill to me. If you don't like 
a commit release team has made to your module, you can simply revert 
it, after all (after ensuring you don't break the GNOME build).

Michael