Scope of GNOME MRU

GNOME has a MicroReleaseException for the SRU process. It is documented to be for:

"GNOME (only the core modules and apps, not the entirety of what is hosted on gnome.org) a(approved on 2012-06-22)" 

Unfortunately, as far as the SRU team is aware, there isn’t anywhere which lists what are the core GNOME modules and apps. There have been a number of SRUs straddling the line - is Vala a core GNOME component? Is librsvg? - and it would be helpful to have a definitive list of the components covered by the MRE.

Ideally this list will end up on the Wiki page, but this seems like a sensible place to decide what should be on that list before putting it there.

From the GNOME pov it’s considered a GNOME component whatever is under the GNOME namespace in gitlab, so: https://gitlab.gnome.org/GNOME/.

However, there are indeed some other dependencies that are core dependencies that might be under the FDO umbrella (or others). So for those (a list can be defined as per gnome-build meta dependencies) I guess we should have some clear statement.

The things under the GNOME namespace might be GNOME components, but I’m pretty sure not all those 400+ projects are core GNOME components - the perl GTK2 bindings, for example, don’t seem likely to be core GNOME anymore :wink:

Pulling out the things under the gnome-build meta, it looks like a sensible list would be

- core/baobab.bst
- core/cheese.bst
- core/eog.bst
- core/epiphany.bst
- core/evince.bst
- core/file-roller.bst
- core/gdm.bst
- core/gedit.bst
- core/gnome-backgrounds.bst
- core/gnome-bluetooth.bst
- core/gnome-boxes.bst
- core/gnome-calculator.bst
- core/gnome-calendar.bst
- core/gnome-characters.bst
- core/gnome-clocks.bst
- core/gnome-color-manager.bst
- core/gnome-contacts.bst
- core/gnome-control-center.bst
- core/gnome-desktop.bst
- core/gnome-disk-utility.bst
- core/gnome-font-viewer.bst
- core/gnome-getting-started-docs.bst
- core/gnome-initial-setup.bst
- core/gnome-keyring.bst
- core/gnome-logs.bst
- core/gnome-maps.bst
- core/gnome-menus.bst
- core/gnome-music.bst
- core/gnome-photos.bst
- core/gnome-remote-desktop.bst
- core/gnome-screenshot.bst
- core/gnome-session.bst
- core/gnome-settings-daemon.bst
- core/gnome-shell-extensions.bst
- core/gnome-shell.bst
- core/gnome-software.bst
- core/gnome-system-monitor.bst
- core/gnome-terminal.bst
- core/gnome-tour.bst
- core/gnome-user-docs.bst
- core/gnome-user-share.bst
- core/gnome-weather.bst
- core/mutter.bst
- core/nautilus.bst
- core/orca.bst
- core/rygel.bst
- core/simple-scan.bst
- core/sushi.bst
- core/totem.bst
- sdk/adwaita-icon-theme.bst
- sdk/glib-networking.bst
- sdk/gsettings-desktop-schemas.bst
- sdk/gvfs.bst
- sdk/yelp.bst

Possibly some more out of sdk/ would be sensible, but that also includes a bunch of stuff that should clearly not be covered, like Kerberos and WebKit .

I would add direct dependencies of all of the above that are in the sdk namespace.

That includes components such as gtk, gdk-pixbuf, gjs, clutter, librsvg (see bug #1884326 for a specific discussion on that one)…

Thank you for discussing this here.

In the case of Vala, I have one further question. As far as I understand, a Vala update will provide no immediate benefit in an SRU except in the case that reverse build dependencies are rebuilt. The current SRU microrelease update request does not request that. So is that worth doing at all? Whether or not Vala is a core GNOME component, is an exception to the exception warranted here? For example: what if we said that we only update Vala if there’s specific SRU-qualifying-under-normal-rules user impact in a package that will be fixed by the Vala update and will also be rebuilt as part of the update?

Otherwise my concern is that we risk introducing regressions by updating Vala that will only expose them on further SRUs of other components, that will be much harder to pin down as a result. On the other hand, not updating Vala would not risk this class of regression, and there wouldn’t be any impact to users of Vala-built packages.

There is one use case not covered here: a user might be directly using Vala as published in Ubuntu to build something not in the archive. I propose to accept SRU requests for that use case on an individually assessed case by case basis.

Another relevant datapoint is bug 1892245. As far as I understand, this is a shell extension that was regressed by a microrelease update to gnome-shell due to a deliberate API change in gnome-shell.

1 Like

The SRU team discussed the GNOME MRE today.

@raof is planning to generate a list of packages that are in-scope based on the above discussion.

There are a couple of exceptional cases in relation to GNOME microrelease updates:

  • We don’t consider that Vala will be included as part of the GNOME MRE. Regardless, the Vala situation is special as it’s generally necessary to also rebuild reverse build dependencies for a Vala SRU to have any effect. If Vala microrelease updates are desired, this will need to be justified and requested independently (whether as a one-off or a standing documented case).

  • Microrelease updates to gnome-shell are at risk of regressing packages providing gnome-shell extensions as we discovered in the case of LP: #1892245. Going forward, we’d like to see suitable mitigations for this type of regression before we publish gnome-shell microrelease updates, such as through thorough testing of reverse dependencies.

Further discussion welcome.

1 Like

So, parsing the BuildStream files and keeping only the first level dependencies in core/ and sdk/ gives the following list:

NetworkManager : core-deps
glib : sdk
gobject-introspection : sdk
pygobject : sdk
vala : sdk
accountsservice : core-deps
upower : core-deps
gdm : core
gtk+-3 : sdk
yelp-tools : sdk
gnome-backgrounds : core
gnome-bluetooth : core
libnotify : sdk
gnome-color-manager : core
gnome-desktop : core
adwaita-icon-theme : sdk
appstream-glib : sdk
gnome-control-center : core
cheese : core
gnome-settings-daemon : core
gdk-pixbuf : sdk
gsettings-desktop-schemas : sdk
gnome-getting-started-docs : core
gnome-initial-setup : core
gnome-keyring : core
WebKitGTK : sdk
geoclue : sdk
gcr : sdk
gnome-menus : core
gnome-remote-desktop : core
libsecret : sdk
pipewire : sdk
gnome-session : core
json-glib : sdk
gnome-shell-extensions : core
gnome-shell : core
librsvg : sdk
mutter : core
gjs : sdk
gst-plugins-base : sdk
libsoup : sdk
gnome-tour : core
gnome-user-docs : core
gnome-user-share : core
nautilus : core
gvfs-daemon : core
graphene : sdk
pango : sdk
zenity : sdk
orca : core
at-spi2-atk : sdk
rygel : core
libgee : sdk
tracker : sdk
sushi : core
evince : core
clutter-gst : sdk
clutter-gtk : sdk
clutter : sdk
gtksourceview : sdk
glib-networking : sdk
baobab : core
gst-plugins-bad : sdk
gst-plugins-good : sdk
eog : core
epiphany : core
file-roller : core
gedit : core
gnome-boxes : core
gnome-calculator : core
gnome-calendar : core
gnome-characters : core
gnome-clocks : core
gnome-contacts : core
gnome-disk-utility : core
gnome-font-viewer : core
gnome-logs : core
gnome-maps : core
gnome-music : core
gnome-photos : core
gnome-screenshot : core
gnome-software : core
gnome-system-monitor : core
gnome-terminal : core
gnome-weather : core
simple-scan : core
totem : core
yelp : sdk
yelp-xsl : sdk
dconf-editor : core
devhelp : core
gtk-doc : sdk
gnome-builder : core
sysprof : core

But this is too restrictive - some things which clearly should be under the GNOME MRE, like evolution-data-server are in core-deps.

Including those gets us the list:

NetworkManager : core-deps
ppp : core-deps
glib : sdk
gobject-introspection : sdk
pygobject : sdk
vala : sdk
accountsservice : core-deps
upower : core-deps
gdm : core
dconf : core-deps
libcanberra : core-deps
plymouth : core-deps
gtk+-3 : sdk
yelp-tools : sdk
gnome-backgrounds : core
gnome-bluetooth : core
libnotify : sdk
gnome-color-manager : core
colord-gtk : core-deps
exiv2 : core-deps
vte : core-deps
gnome-desktop : core
adwaita-icon-theme : sdk
appstream-glib : sdk
gnome-control-center : core
ModemManager : core-deps
colord : core-deps
gnome-online-accounts : core-deps
grilo : core-deps
gsound : core-deps
ibus-daemon : core-deps
libgtop : core-deps
libhandy : core-deps
libnma : core-deps
malcontent : core-deps
samba : core-deps
system-config-printer : core-deps
udisks2 : core-deps
cheese : core
gnome-settings-daemon : core
gdk-pixbuf : sdk
gsettings-desktop-schemas : sdk
gnome-getting-started-docs : core
gnome-initial-setup : core
libgweather : core-deps
gnome-keyring : core
WebKitGTK : sdk
geoclue : sdk
gcr : sdk
gnome-menus : core
gnome-remote-desktop : core
LibVNCServer : core-deps
freerdp : core-deps
libsecret : sdk
pipewire : sdk
gnome-session : core
json-glib : sdk
cups-pk-helper : core-deps
geocode-glib : core-deps
gnome-shell-extensions : core
gnome-shell : core
librsvg : sdk
evolution-data-server : core-deps
gnome-autoar : core-deps
startup-notification : core-deps
mutter : core
gjs : sdk
gst-plugins-base : sdk
libsoup : sdk
gnome-tour : core
gnome-user-docs : core
gnome-user-share : core
nautilus : core
gvfs-daemon : core
graphene : sdk
pango : sdk
zenity : sdk
orca : core
pyatspi : core-deps
speech-dispatcher : core-deps
at-spi2-atk : sdk
rygel : core
gssdp : core-deps
gst-editing-services : core-deps
gupnp-av : core-deps
gupnp-dlna : core-deps
gupnp : core-deps
libmediaart : core-deps
libgee : sdk
tracker : sdk
sushi : core
libmusicbrainz : core-deps
evince : core
clutter-gst : sdk
clutter-gtk : sdk
clutter : sdk
gtksourceview : sdk
glib-networking : sdk
baobab : core
gnome-video-effects : core-deps
gst-plugins-bad : sdk
gst-plugins-good : sdk
eog : core
exempi : core-deps
libpeas : core-deps
epiphany : core
libdazzle : core-deps
gspell : core-deps
libgxps : core-deps
file-roller : core
gedit : core
amtk : core-deps
tepl : core-deps
gnome-boxes : core
gtk-vnc : core-deps
libhandy-0 : core-deps
libosinfo : core-deps
libvirt-glib : core-deps
osinfo-db : core-deps
spice-gtk : core-deps
tracker-2 : core-deps
tracker-miners-2 : core-deps
gnome-calculator : core
mpc : core-deps
gnome-calendar : core
gnome-characters : core
gnome-clocks : core
gnome-contacts : core
folks : core-deps
gnome-disk-utility : core
libdvdread : core-deps
gnome-font-viewer : core
gnome-logs : core
gnome-maps : core
libchamplain : core-deps
libgfbgraph-0.2 : core-deps
gnome-music : core
grilo-plugins : core-deps
tracker-miners : core-deps
gnome-photos : core
babl : core-deps
gegl : core-deps
gexiv2 : core-deps
gnome-online-miners : core-deps
libgdata : core-deps
gnome-screenshot : core
gnome-software : core
eos-updater : core-deps
flatpak : core-deps
fwupd : core-deps
liboauth : core-deps
xmlb : core-deps
gnome-system-monitor : core
gtkmm-3 : core-deps
gnome-terminal : core
gnome-weather : core
simple-scan : core
libgusb : core-deps
sane-backends : core-deps
totem : core
totem-pl-parser : core-deps
yelp : sdk
yelp-xsl : sdk
dconf-editor : core
devhelp : core
gtk-doc : sdk
gnome-builder : core
flatpak-builder : core-deps
jsonrpc-glib : core-deps
libgit2-glib : core-deps
template-glib : core-deps
sysprof : core

Which is clearly too much; upower, plymouth, and exiv2 definitely don’t belong in the GNOME MRE.

So I think we need to manually curate this list. As a first, proposal, I’ll put up:

glib : sdk
gobject-introspection : sdk
pygobject : sdk
gdm3 : core
gtk+-3 : sdk
yelp-tools : sdk
gnome-backgrounds : core
gnome-bluetooth : core
libnotify : sdk
gnome-color-manager : core
gnome-desktop : core
adwaita-icon-theme : sdk
gnome-control-center : core
gnome-online-accounts : core-deps
grilo : core-deps
gsound : core-deps
libhandy : core-deps
cheese : core
gnome-settings-daemon : core
gdk-pixbuf : sdk
gsettings-desktop-schemas : sdk
gnome-getting-started-docs : core
gnome-initial-setup : core
libgweather : core-deps
gnome-keyring : core
gcr : sdk
gnome-menus : core
gnome-remote-desktop : core
gnome-session : core
json-glib : sdk
gnome-shell-extensions : core
gnome-shell : core
librsvg : sdk
evolution-data-server : core-deps
gnome-autoar : core-deps
startup-notification : core-deps
mutter : core
gjs : sdk
gst-plugins-base : sdk
gnome-tour : core
gnome-user-docs : core
gnome-user-share : core
nautilus : core
gvfs-daemon : core
rygel : core
tracker : sdk
sushi : core
evince : core
clutter-gst : sdk
clutter-gtk : sdk
clutter : sdk
gtksourceview : sdk
glib-networking : sdk
baobab : core
gnome-video-effects : core-deps
eog : core
epiphany : core
file-roller : core
gedit : core
gnome-boxes : core
gtk-vnc : core-deps
libhandy-0 : core-deps
tracker-2 : core-deps
tracker-miners-2 : core-deps
gnome-calculator : core
gnome-calendar : core
gnome-characters : core
gnome-clocks : core
gnome-contacts : core
folks : core-deps
gnome-disk-utility : core
gnome-font-viewer : core
gnome-logs : core
gnome-maps : core
gnome-music : core
grilo-plugins : core-deps
tracker-miners : core-deps
gnome-photos : core
gnome-online-miners : core-deps
gnome-screenshot : core
gnome-software : core
gnome-system-monitor : core
gtkmm-3 : core-deps
gnome-terminal : core
gnome-weather : core
simple-scan : core
totem : core
totem-pl-parser : core-deps
yelp : sdk
yelp-xsl : sdk
dconf-editor : core
devhelp : core
gtk-doc : sdk
gnome-builder : core

I think some of those are marginal; feel free to suggest ones to remove. Are there any that definitely should be in there that I’ve missed?

So… To make this clear, this is what you’re removing from the full list:

+++ /tmp/post	2020-09-18 12:04:29.831625142 +0200
@@ -1,41 +1,20 @@
-NetworkManager : core-deps
-ppp : core-deps
 glib : sdk
 gobject-introspection : sdk
 pygobject : sdk
-vala : sdk
-accountsservice : core-deps
-upower : core-deps
 gdm3 : core
-dconf : core-deps
-libcanberra : core-deps
-plymouth : core-deps
 gtk+-3 : sdk
 yelp-tools : sdk
 gnome-backgrounds : core
 gnome-bluetooth : core
 libnotify : sdk
 gnome-color-manager : core
-colord-gtk : core-deps
-exiv2 : core-deps
-vte : core-deps
 gnome-desktop : core
 adwaita-icon-theme : sdk
-appstream-glib : sdk
 gnome-control-center : core
-ModemManager : core-deps
-colord : core-deps
 gnome-online-accounts : core-deps
 grilo : core-deps
 gsound : core-deps
-ibus-daemon : core-deps
-libgtop : core-deps
 libhandy : core-deps
-libnma : core-deps
-malcontent : core-deps
-samba : core-deps
-system-config-printer : core-deps
-udisks2 : core-deps
 cheese : core
 gnome-settings-daemon : core
 gdk-pixbuf : sdk
@@ -44,19 +23,11 @@
 gnome-initial-setup : core
 libgweather : core-deps
 gnome-keyring : core
-WebKitGTK : sdk
-geoclue : sdk
 gcr : sdk
 gnome-menus : core
 gnome-remote-desktop : core
-LibVNCServer : core-deps
-freerdp : core-deps
-libsecret : sdk
-pipewire : sdk
 gnome-session : core
 json-glib : sdk
-cups-pk-helper : core-deps
-geocode-glib : core-deps
 gnome-shell-extensions : core
 gnome-shell : core
 librsvg : sdk
@@ -66,30 +37,14 @@
 mutter : core
 gjs : sdk
 gst-plugins-base : sdk
-libsoup : sdk
 gnome-tour : core
 gnome-user-docs : core
 gnome-user-share : core
 nautilus : core
 gvfs-daemon : core
-graphene : sdk
-pango : sdk
-zenity : sdk
-orca : core
-pyatspi : core-deps
-speech-dispatcher : core-deps
-at-spi2-atk : sdk
 rygel : core
-gssdp : core-deps
-gst-editing-services : core-deps
-gupnp-av : core-deps
-gupnp-dlna : core-deps
-gupnp : core-deps
-libmediaart : core-deps
-libgee : sdk
 tracker : sdk
 sushi : core
-libmusicbrainz : core-deps
 evince : core
 clutter-gst : sdk
 clutter-gtk : sdk
@@ -98,65 +53,37 @@
 glib-networking : sdk
 baobab : core
 gnome-video-effects : core-deps
-gst-plugins-bad : sdk
-gst-plugins-good : sdk
 eog : core
-exempi : core-deps
-libpeas : core-deps
 epiphany : core
-libdazzle : core-deps
-gspell : core-deps
-libgxps : core-deps
 file-roller : core
 gedit : core
-amtk : core-deps
-tepl : core-deps
 gnome-boxes : core
 gtk-vnc : core-deps
 libhandy-0 : core-deps
-libosinfo : core-deps
-libvirt-glib : core-deps
-osinfo-db : core-deps
-spice-gtk : core-deps
 tracker-2 : core-deps
 tracker-miners-2 : core-deps
 gnome-calculator : core
-mpc : core-deps
 gnome-calendar : core
 gnome-characters : core
 gnome-clocks : core
 gnome-contacts : core
 folks : core-deps
 gnome-disk-utility : core
-libdvdread : core-deps
 gnome-font-viewer : core
 gnome-logs : core
 gnome-maps : core
-libchamplain : core-deps
-libgfbgraph-0.2 : core-deps
 gnome-music : core
 grilo-plugins : core-deps
 tracker-miners : core-deps
 gnome-photos : core
-babl : core-deps
-gegl : core-deps
-gexiv2 : core-deps
 gnome-online-miners : core-deps
-libgdata : core-deps
 gnome-screenshot : core
 gnome-software : core
-eos-updater : core-deps
-flatpak : core-deps
-fwupd : core-deps
-liboauth : core-deps
-xmlb : core-deps
 gnome-system-monitor : core
 gtkmm-3 : core-deps
 gnome-terminal : core
 gnome-weather : core
 simple-scan : core
-libgusb : core-deps
-sane-backends : core-deps
 totem : core
 totem-pl-parser : core-deps
 yelp : sdk
@@ -165,8 +92,3 @@
 devhelp : core
 gtk-doc : sdk
 gnome-builder : core
-flatpak-builder : core-deps
-jsonrpc-glib : core-deps
-libgit2-glib : core-deps
-template-glib : core-deps
-sysprof : core

That said, there are some that are clearly GNOME projects and on which mostly GNOME core apps depend on (there could be few external cases) and where upstream can be trusted that a new point release works with the whole ecosystem.
Such as:

at-spi2-atk
gspell
gssdp
libcanberra
libdazzle
libgdata
libgee
libgit2-glib
libgtop
libgusb
libpeas
libsoup # Maybe this could be kept away
pyatspi
sysprof
template-glib
vte # There may be gnome-terminal SRUs that require bumping this as well
zenity

That being said, I think we should also define a procedure (that should be quite straight forward) to update the list whenever new upstream GNOME projects have been added (or moved away from the GNOME umbrella).

1 Like

@3v1n0

Moving this conversation here as this thread is about SRU policy vs. the other one that is only about a specific update.

Assuming that you mean adding a Breaks: package relationship in a gnome-shell microrelease SRU, such that extensions installed from the archive will need to be removed before gnome-shell can be upgraded, I’m not sure that’s safe. If there’s a subsequent security update to gnome-shell, what’s that going to mean for users who are using such shell extensions from the archive? Will apt refuse to install the security update, or will apt force the removal of the extension packages? Either way seems unacceptable to me.

I think an essential requirement for an SRU is that nothing in the archive is knowingly broken as a result of it. We released with these extension packages, and our stability promise we make is that we won’t break them. It then follows that declaring “extensions we can’t support” cannot be used as an excuse to break this promise. However this is probably outside of the scope of the SRU team to decide; I think that if we want to deliberately break compatibility with other packages in the archive in an SRU, then that’s outside the scope of the microrelease update permission given to the SRU team by the Technical Board and so such an exception proposal would have to go back to the Technical Board for their consideration.

An alternative might be not to release such extension packages at all if they’re going to block gnome-shell microrelease updates like this because nobody is committing to do the necessary work. I am generally in favour of removing packages that aren’t being looked after and are also blocking progress. Again that’s not up to the SRU team though; that’d be something to clear with the release team.

Note however that in the case of this particular regression we found that people are using the package and @fcole90 did step up to do the necessary work. Whatever we do, I think we need to figure out how to fit those extension packages into the gnome-shell SRU process so that those who are willing to look after these packages like this can continue to do so without users being regressed first.

1 Like

I concur, with the caveat that there are sometimes cases where breaking a package in the archive is the least-worst choice.

Certainly each instance would need to be judged individually. The GNOME MRE should not be a blanket permission to break packaged¹ extensions; all packaged extensions should be tested against a new GNOME Shell, and any regressions should be flagged and investigated to see if they can be resolved.

¹: As our policy is that people using 3rd party repositories are on their own, and extensions.gnome.org is a 3rd party repository, it is acceptable (although not ideal) to break unpackaged extensions in a gnome-shell SRU.

Sure, my point wasn’t to break it in a SRU, but to ensure that those mostly unmaintained extensions (I personally maintain the dashtodock one, even upstream, but I normally just package it in the ubuntudock variant) don’t figure out as supported by us before the release.

While debian may have other preferences on that, IMHO it’s not possible to ensure that all the extensions in archive (41 right now!!) are not broken by some detail of an upstream update.
And this is mostly for the nature of the Shell, that being in JavaScript gives us very few tools to ensure if an “API” has changed or not (considering also that most of those extensions use internal properties that shell upstream developers change all the times).

So this would imply run them all, and you’d need to go one-by-one and check the shell logs (as running them all together could lead to other breakages of course).

1 Like

In that case, I think this means that we cannot (continue to) push microrelease updates of gnome-shell to stable releases because such updates are known to break packaged extensions. The microrelease exception was originally granted by the technical board on the basis that such updates are not expected to break things, and that situation has clearly changed in the case of gnome-shell.

Fixes to gnome-shell will have to be individually cherry-picked and tracked using the usual SRU method. That allows for consideration of accidentally regressing extensions on an individual and more narrowly scoped basis. A grep through the extensions for object API attributes that are being modified in behaviour or being removed should also then be more practical.

I understand this is undesirable, but I don’t see that we have any other choice. It’s a consequence of shipping those extension packages in the first place. Personally I’m in favour of ceasing to ship unmaintained extension packages in future releases. That would resolve this problem and allow gnome-shell microrelease updates to resume in future releases I think, by making testing of extensions during gnome-shell SRU verification practical? If you agree with this approach, I suggest you take it up with the release team.

1 Like

In that case, I think this means that we cannot (continue to) push microrelease updates of gnome-shell to stable releases because such updates are known to break packaged extensions. The microrelease exception was originally granted by the technical board on the basis that such updates are not expected to break things, and that situation has clearly changed in the case of gnome-shell.

Well, we had so far one recorded case, for an extension that we don’t officially support and that can be fixed also at some later times, indeed this was an unfortunate thing but still it was a minimal impact compared to the tenths of fixes that the silent majority of our users got by getting new point releases earlier.

So, really I don’t see the rational why a such minor problem can just be the reason for making harder and slower for most of users to get a better quality software.

A grep through the extensions for object API attributes that are being modified in behaviour or being removed should also then be more practical.

This is not possible, as said… They may act on the same elements in too many ways that a grep that would work fine in C isn’t applicable to JS monkey-patching.

Fixes to gnome-shell will have to be individually cherry-picked and tracked using the usual SRU method. That allows for consideration of accidentally regressing extensions on an individual and more narrowly scoped basis.

I’m not really sure how this would change the things, if there are regressions and the shell gets verified for the N fixed bugs, it doesn’t mean that it regresses on something else that has not been taken in consideration (nor that could be taken in consideration) when writing the regresssion potential line.

1 Like

I think you’re conflating “we” here. By “we” I think you mean Canonical, but wearing my SRU team hat I’m speaking for the Ubuntu archive, which is a community project. In that sense, the extension is being supported by volunteers, and we must not undermine the Ubuntu community by ignoring them.

I don’t think regressions that we’ve overlooked are relevant here. The key difference is that we will have carefully considered and done our best to avoid regressing users if we follow the usual process, whereas if we continue to follow your current process then we will be deliberately refusing to even look to check that we haven’t regressed something.

Hey there, thanks @rbasak and @raof for leading the discussion from the SRU team perspective and @3v1n0 for representing the desktop team position.

The options have been discussed in the desktop meeting and the removal of deb extensions from the archive seems the only realistic approach with the available resources, that’s discussed on https://discourse.ubuntu.com/t/removal-of-gnome-shell-extension-from-universe-and-stop-auto-syncs now

The LTS update is including important fixes and blocking on the basis that it could regress some almost not used universe extensions is quite unfortunate. Realistically users are going to have extensions enabled by other ways and found their system broken in a similar fashion by the update (upstream and SRU), it’s not really something in our hands.
If the SRU team insists that this update is going to need stricter standards that the previous ones we did in focal up to now then the only remaining option is to try to organize testing of the universe available extensions, that is costly in resources and we would prefer to spend effort on more useful problems though…

The SRU team is not blocking this. You can continue to land SRUs for gnome-shell providing that you continue to test such SRUs adequately. What “adequate” means is still up for discussion. However, we now know that gnome-shell upstream microreleases make no effort to maintain API that our extension packages depend on. A regression caused by this API instability has happened in practice. So I am rejecting the idea that you can completely ignore the extension packages. However we haven’t discussed details of exactly how to ensure that extension packages haven’t regressed, and I’m open to discussing pragmatic/realistic approaches to achieve this.

Do you have any data to support your claim of “almost not used universe extensions”? I got the impression that the dash-to-panel extension is quite popular. In any case, we released with these packages. SRU policy has always been that we take appropriate steps not to regress what we released.

There is no change to the standard here. I’m open to making pragmatic exceptions, but I think it’s disingenuous to imply that the standard has changed. gnome-shell microreleases fell short of the standard required. Based on the information we had, we had thought that the gnome-shell upstream microrelease process met the required standard, but it turned out that it does not. We now need to figure out how best to meet the required standard again. That is all.

We don’t have metrics but it’s an universe package users need to opt in for and the number of reports was low when it stopped working, anyway whether it’s 3% or 0.01% of users isn’t going to make a difference is it? Going forward we should just remove those to avoid the issue and then we need to focus out what testing needs to happen on the current LTS

I think we might also want to remove Tracker from the GNOME MRE list?

My understanding is that the MRE is granted on the basis that we have a shared understanding with GNOME what a bugfix release is, and the changelog for the 2.3.4 → 2.3.6 SRU appears to include two things that aren’t obviously bugfixes - an entirely new tracker export command, and renaming some functions for no functional change.

Am I being too picky, here?