On 21/03/2020 13:17, Simon McVittie wrote: > > It would probably make most sense to treat gnome-desktop3 and mutter as > > a single transition, as we have often done in the past: upstream will > > not have tested arbitrary mixtures of 3.34 and 3.36.
Progress on this: After chasing regressions for the last few days, I think we have Shell in a good state to consider doing this transition. This would involve uploading the following experimental GNOME packages to unstable as a batch: * gnome-desktop3 * gjs * mutter * gnome-shell * gnome-shell-extensions Ubuntu have already done this transition for 20.04 'focal', so I hope the Ubuntu people in the GNOME team can give us an idea of the level of breakage without us having to do our own test-rebuild in Debian. I'm told the only significant porting work needed in Ubuntu was in Unity. gnome-desktop3 ABI breaks have mostly been handled via binNMUs in the past, without being particularly problematic. budgie will need rebuilding against the new mutter, but seems to have already been patched to cope with either the old or new API/ABI. gnome-shell-xrdesktop (a "friendly fork" of gnome-shell with an experimental 3D UI for VR headsets) will need either updating to 3.36.x to match (#956147) or removing from testing for a while. I am not able to test this, and I suspect the rest of the GNOME team are in the same situation; I don't think we should let gnome-shell-xrdesktop (popcon: 0) hold back gnome-shell (popcon: 37K votes). Third-party GNOME Shell extensions are likely to regress (they do that a lot, because they work by monkey-patching GNOME Shell internals). I think we should remove any problematic extensions from testing rather than let them hold up Shell. Of the three I maintain myself, I have uploaded a fixed version of one to experimental, and confirmed that the other two work acceptably as-is. Hopefully that's a reasonably representative sample. My next upload of gnome-shell will hopefully add a workaround for one major source of regressions in extensions, which is that the way older extensions invoke a preferences dialog is no longer supported (#956172 and similar bugs). Extensions will still need fixing for this before 3.38 or for use on other distros, but the workaround removes the immediate urgency. smcv