Re: Bug#954422: transition: GNOME 3.36
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
Reply to: