As briefly discussed in the Ubuntu desktop team meeting, we believe that maintaining extensions that are not under the direct responsability of the Desktop team and that are published and (meant to be) updated via e.g.o it does not add any value to ubuntu, but can only create more breakage as in the recent dash-to-panel case.
Given this, we propose to:
Remove all the gnome-shell-extension-* packages that are in Universe
Stop auto-sync for them all
If community wants to maintain some of them it’s fine, but we need to have some clear statement clarifying that such support will be maintained for the whole LTS time, or we won’t be able to accept them anyways.
As per this, would be nice to have the release team opinion on such proposal.
I think the proposed requirement from the SRU team to manually test all 40+ extensions in the Ubuntu archive (so long as they are still in there) when SRUing new upstream releases is completely unsustainable, and would result in practice in GNOME Shell updates, containing important bug fixes, not being SRUed at all. This seems like the only feasible way out to me.
On balance I think deferring to the method that GNOME upstream provides, extensions.gnome.org, offers an acceptable experience given this new requirement. In the very slim chance that there is a break in a stable release, the upstream extension author is able to directly ship a fix. This seems very unlikely to happen in practice in Ubuntu until after the problem surfaces in -updates. The obvious downside is that the functional stability provided by the distro is not guaranteed any more.
Interested in hearing the opinions of other members of the desktop & release teams, though.
Wearing my SRU team hat (I do not own a release team hat), I’m in favour of this plan as it seems like the only reasonable way to get gnome-shell updated in stable releases without regressing extension packages in the archive that nobody is looking after. This is one case where autosync from Debian is harmful for us. Specifically, the harmful alternatives are:
Risk regressing extension packages pulled in [and released] by autosync when we SRU gnome-shell because nobody will be testing them.
Require a very large amount of work testing all the extension packages for regressions before landing any gnome-shell microrelease update.
Given that extension packages are available out-of-archive anyway, it seems to me that for unmaintained extension packages, a better option would be not to release with them at all.
I don’t think it’s fair to frame this as a new requirement. It has always been the requirement to perform adequate testing before landing SRUs. The only thing that has changed is that we now understand that gnome-shell upstream microreleases are not stable with respect to extension packages. This means that what we previously considered to be “adequate testing” clearly isn’t adequate.
My 2p as a user: I never install extensions from the package manager, but from the gnome extensions website. I can only imagine the burden on you maintainers of keeping up with breakage and whatnot on stuff users should be getting via the proper upstream channel.
Sorry for bring up edge cases, but there are some source packages that provide a GNOME Shell extension that extends an app. Sometimes, the extension is a separate binary package like gpaste; sometimes it’s not like gnome-shell-pomodoro. This isn’t something that can be completely provided by extensions.gnome.org (Neither of these are provided on that website.)
There are a few other examples you can find by browsing the output of
I second what Jeremy has written above, please don’t remove the applications that package shell extensions because those kinds of extensions are not published on the extensions’ website.
I’m very sorry to hear this, as I always use dash-to-panel from the repos for stability (and recently SRUed that as mentioned by @3v1n0), but indeed I understand that the current situation is unsustainable. So, are all extension being removed entirely or will they move to a different repo (like multiverse)?
gnome-shell-extension-appindicator
gnome-shell-extension-desktop-icons-ng
gnome-shell-extension-ubuntu-tiling-assistant (as of 23.10 but available for 23.04)
gnome-shell-extension-ubuntu-dock
Default Edubuntu Install
gnome-shell-extension-alphabetical-grid
Maintained by GNOME
gnome-shell-extensions (provides the GNOME Classic extension set)
Bundled with an app or service
gnome-shell-extension-gsconnect
gnome-shell-mailnag (Not provided in Ubuntu 23.10)
gnome-shell-pomodoro
gnome-shell-extension-gpaste
terminus
workrave-gnome (Broken with Ubuntu 23.04, works with 23.10)
blocklist
Everything not on this list will no longer be available as an Ubuntu package (and would be added to our autosync blocklist)
While I have no strong opinion on this topic, the timing for doing it is not optimal considering that the FF .deb just has been dropped and the FF snap does currently not have the ability to install extensions directly from GNOME.
Thank you for your feedback! Our goal is for the Firefox snap to support web extensions including the GNOME Shell extensions helper by the time Ubuntu 22.04 LTS is released.
Also, we will have mjakeman’s very useful GNOME Shell Extensions Manager app available in the Ubuntu 22.04 LTS repositories (but not installed by default). OMG! Ubuntu has a new post today about the latest 0.3 version (I think we’ll be able to get that version packaged for 22.04 too). You can install extensions directly from the app; no web browser needed.
As above I’m in favour of this plan, but can I just check that you’re aware that you need an approval from the release team to remove the other extension packages? I think you’d need to add them to the autosync blocklist as well.
The rationale and justification are that we believe children should be able to understand alphabetizing and cataloguing (we have application folders per educational subject), and this extension is multi-language localized. By having their desktop environment already catalogued and alphabetized, this sets that example and the computer itself becomes a better learning tool.
