> 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.
There's also c) include a temporary patch in gnome-build-meta till the MR is merged, though git will complain about the patch being already applied once merged and break the build. There's also d) pin the module to your branch/fork of the MR which fixes the build, and open an issue against build-meta with a due date in 2 days or so to remove it and so its not forgotten. Cheers, Jordan ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, January 14th, 2021 at 7:02 PM, Michael Catanzaro <mcatanz...@gnome.org> wrote: > On Thu, Jan 14, 2021 at 11:04 am, Philip Withnall > > phi...@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 > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
