On Fri, 13 Sep 2024 at 14:16:29 -0400, Jeremy Bícha wrote:
> - GNOME Shell
This is the only one of the three batches you described that is really
in-scope for #1081519, and I think the only one that really needs a
transition slot from the release team.
> Some things like xwayland scaling won't work right if we don't have
> gnome-settings-daemon >= 47~rc. The build tests do pass if retried a
> few times. [...] If it helps, we only started running this mutter
> set of tests in July because we didn't notice earlier we had tests
> that were not being run.
OK, then we want gnome-settings-daemon to be in-scope for #1081519. To
me, this is sounding like: the gnome-settings-daemon tests are not yet
reliable enough to be a QA gate, so we should just disable the flaky ones
(or perhaps all of them).
I would say that manual testing on real GNOME systems is much more
practically important for g-s-d than its build-time unit tests.
> - gjs with the switch to mozjs128. Years ago, gjs updates were
> disruptive but not really anymore. We are doing some armel surgery
> this time though.
This is a separate sort-of-transition, #1080521. It doesn't involve an
ABI break as such, but it will require ftp team action (removing NBS
binaries from armel) to get it into testing, so I opened a release team
bug to check that they were aware and we weren't trying to do anything
impossible.
The main risk here is that if NBS binaries aren't removed reasonably
quickly, it could stall migrations and interfere with a transition.
> - gtk4 + libadwaita + all the GNOME 47 app & library updates that are
> not in Unstable already and not part of the other 2 categories
This is tracked by the GNOME team as #1079548. It isn't really a
transition as such, everything in it is backwards-compatible (no ABI
breaks) as far as I'm aware.
Unfortunately it's now blocked by Weston 14, which is crashing when
we use it to run the GTK 4 test suite, causing the test suite to fail
as collateral damage (#1081515); we can't upgrade gtk4 until that's
resolved somehow, either by fixing Weston or by using a different
headless compositor to run our tests. I tried to use wlheadless-run from
the xwayland-run package, wrapping mutter or cage instead of weston,
but I haven't had any success with that yet.
smcv
