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

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).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]