Mutter / GNOME Shell are no longer covered by the GNOME MRE

Project Discussion Desktop
21

I consulted with other SRU team members on this.

As ubuntu desktop we really only support what we ship…

No, this is not correct.

For example, if we were to SRU Python, and that broke some behaviour such that some third party library users were installing with pip stopped working as a result of something that we all agreed was a bug in Python itself that we regressed, then that is something we would treat as an SRU regression and fix. Further, we would try to avoid landing that regression in an SRU in the first place. Of course predicting such a regression is difficult to do in practice, but in principle when reviewing the SRU we would be thinking about what we might regress in a Python SRU where the use case that might break could well be outside the archive.

In the general case, this applies to everything in an Ubuntu stable release. Things outside our control can change, and the point of an Ubuntu stable release is that we try to avoid break anything a user might reasonably do when using a stable Ubuntu release as a platform. This does, very intentionally, limit the scope of Ubuntu SRUs.

Therefore, again speaking in the general case, pointing out that something that might break is entirely a concern outside the archive is not a free pass for ignoring it as a potential source of SRU regression.

We must therefore consider the specific case. What we care about is the extent of the possible breakage and finding an appropriate balance for our users.

To consider this specific case SRU team therefore has the following questions:

  1. What is upstream’s position on extension API today? Do they have a rule about breaking API that extensions use in microreleases now? Will they highlight these things in release notes?

  2. How likely is it it that by the time we upload a microrelease, extensions.gnome.org will have been updated to fix any breakages? Would it make sense and help if we delayed the SRU to give these extensions time to adapt?

  3. How widely are our gnome-shell version selections in our releases used outside Ubuntu? Eg. Noble uses gnome-shell 46. Who else in the ecosystem is still using 46, or is it just Ubuntu? What about Jammy? The concerns here are 1) that extensions authors wouldn’t be bothered with gnome 46 by now; 2) they will only notice and fix extensions only after Ubuntu lands a gnome-shell change that regresses users first.

If you like, we can meet in realtime to discuss these points.

22

Well, at the moment in order to use extensions that are not the default one you already have to toggle a setting manually.

Would make any difference if when an user enables the extensions we would notify them with a message saying something like non system extensions are not supported by Ubuntu. By installing an extensions you potentially provide access to your data. And by using them you accept that they can break with GNOME shell updates.

After all this is something that we already do (breaking user extensions) on LTS-to-LTS update.

As I mentioned (and I’m representing both upstream and downstream FWIW here), the extension official public API does not change in releases.

But extensions can modify also private API aspects, so a release can break an extension that is touching private elements (it’s JS after all and the use of #private fields is not yet very frequent).

But again, also cherry-picking a fix using the standard SRU procedure, may break any extension (maybe with just 1 user) without being ever noticed.

e.g.o is like pypi, anyone can upload anything when they want, so not really something we can control.

However, given that distros like fedora basically update gnome shell as soon as it is released upstream, it’s very likely that extension authors receive bugs and update the extensions quite early in case of breakage.

So, in case we find clear regressions in (very well know) extensions we may indeed give some time to the authors to fix them.

In fact here I’m not asking for the MRE as it was before or as it is for other packages, I’m totally open to experiment and define different processes, but with the final goal of having the latest stable releases eventually being uploaded to the distro.

So for example, I’ good if we say, that we release a stable release version by the time the next one is released upstream (e.g. we prepare 50.1 to be released when 50.2 is out, while if we want to cherry-pick something from 50.2 it goes through the normal process).

It depends a bit on the years, for example at times we’re in sync with RHEL or other LTS versions, so that makes it easier to share users with.

However, for the first point releases, most of distros update in time (see the current state for 49 for example)

And 1. and 2. are valid concerns, when it comes to upload versions that are released a year or so later. But I don’t think we can do much more than test as much as it’s possible and see if we break something.

Technically, some basic tests could be automated (for some main extensions) during autopkgtests (but we’d require network access) like:

  • Install an extension
  • Run the shell in test mode
  • See if the extension is broken (we can’t do functional tests, but check if it reported syntax errors for example, or it tries to do something wrong during the startup that breaks it)

But, I don’t think we’ve the resources to do much more than that.

Anyways, It’s still unclear to me why this would be different in the current process: we are not required to test all the extensions out there, but any cherry pick we do may break an extension that touches the private shell API.

If you like, we can meet in realtime to discuss these points.

Sure happy to, let’s setup something.

1 Like