GNOME 45 update will break all extensions
There's an open OBS request to update GNOME shell to 45.rc [1]. This update will break every existing GNOME extension [2,3]. As one of the pitiable individuals who have volunteered to co-maintain a few GNOME extensions in the past, I'd like to suggest that this update be postponed at least a few weeks. (No, not every extension maintainer follows GNOME beta releases). I'm particularly surprised that this updated is pushed to Factory while this is still in RC stage upstream. Is it really necessary to rush this breaking change in this way? Martin [1] https://build.opensuse.org/request/show/1110494 [2] https://gjs.guide/extensions/upgrading/gnome-shell-45.html#esm [3] https://news.itsfoss.com/gnome-45-extensions/
On Thu, 2023-09-14 at 17:36 +0200, Martin Wilck via openSUSE Factory wrote:
There are no extensions inside the distribution. Speaking as as an openSUSE developer; I think Tumbleweed should release based on criteria it controls or at least influences. External third party extensions do not meet that very basic criteria. Speaking as a long time GNOME user/contributor; If maintainers of those extensions haven't been keeping up with what's been going on with GNOME 45, I'm not sure I'm comfortable using their extension anyway. This change was communicated well in advance, like all GNOME changes. I would very much like my MicroOS Desktop/Aeon users to have GNOME 45 promptly. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
On Fri, 2023-09-15 at 10:02 +0200, Richard Brown wrote:
False. A simple "zypper search gnome-shell-extension" brings up 10 matches, with just official factory repos.
It's new to me that Tumbleweed has an influence on GNOME releases. But even assuming that was true, again, why can't Tumbleweed at least wait for the official upstream release?
Speaking as another long time GNOME user, occasional bug reporter and fix contributor, and extension maintainer: There are lots of extensions which have have proven to be stable and useful over years. Under normal circumstances, these extensions would require almost zero maintenance and still remain stable and useful. But GNOME shell keeps breaking extensions with every other major release, causing considerable effort on the extension-writer's part every time. That's extremely frustrating. It's no secret that some extension writers have given up [1]. Expecting every extension writer to keep up with GNOME core development is just unrealistic. It's like demanding that every application writer follow kernel development. No! Linus keeps the user space API stable. I wish the GNOME core developers were only 10% as considerate about their extension authors as Linus is about applications.
This change was communicated well in advance, like all GNOME changes.
Breakage that's communicated early is still breakage, and it depends on the PoV what "well in advance" means and if it's sufficient. I understand that breakage is sometimes unavoidable; I don't know whether that was the case for GNOME 45. All am asking for is some more time.
I would very much like my MicroOS Desktop/Aeon users to have GNOME 45 promptly.
Thanks for explaining your preference. I infer that Aeon users don't depend on any extensions? That surprises me. I think I'm not the only person who considers GNOME shell without extensions hardly usable for day-to-day work. Martin [1] Sample rant of a frustrated developer here: https://github.com/p-e-w/argos/issues/108#issuecomment-585076628
Le vendredi 15 septembre 2023 à 11:53 +0200, Martin Wilck via openSUSE Factory a écrit :
It always does. Just because some sr were done to openSUSE Factory doesn't mean they will be accepted and released immediately. As usual, openSUSE GNOME team is pushing RC to Factory STAGING so they could be validated in openQA in advance, either updating openQA needles in advance or fixing other packages. And when final tarball are available, new SR will replaces the old one which didn't land in Factory. This is not something new. -- Frederic CROZAT Enterprise Linux OS and Containers Architect SUSE
On Fri Sep 15, 2023 at 11:53 AM CEST, Martin Wilck via openSUSE Factory wrote:
If you haven’t notice that GNOME core developers don’t give a damn for anything outside of their own projects, then you must be new here. Why should they care for gnome-externsions authors more than they (don’t) care for GNOME applications developers? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. -- http://dwm.suckless.org/
On Sat, 2023-09-16 at 08:05 +0200, Matěj Cepl wrote:
Oh, I noticed this before. I just didn't say it loud here.
Why should they care for gnome-externsions authors more than they (don’t) care for GNOME applications developers?
I have no experience with GNOME application development, but yeah, I guess it can suck, too. Martin
On Thu, 09/14/2023 at 17:36 +0200, Martin Wilck wrote:
Hi there Martin, While I sympathize with you -- I really do as I do use a few, and I've seen many extensions breakage over and over and over --, the idea of postponing our release for at least a few weeks doesn't appeal to me at all. We don't have enough man power to coordinate such deliberate delay, and I'm not sure that it would be a good idea in general. Yes, I'm aware that there are people relying on extensions to make the most out of GNOME for their needs, be it specific or not. However, I'm not sure that's the best way to handle all of this, either. The sooner the release gets used/tested by the general user, the more issues get uncovered by them and (hopefully) reported, at least in theory. The sooner issues get fixed, the happier users (hopefully) become, in theory. And this should be a valid concern to all the GNOME components, to the very least, which are part of the core, and that such delay would hold back. Just like upstream has their own problems getting new contributors -- yes, GNOME is a non-profit organization after all. And even though there are many paid developers working on it, contributors still are a major driving force that greatly helps move development forward. That makes edges around the corner rougher than they should be, and unstable API for third-party GNOME extension developers to rely on being one of the things that get overlooked -- we also do, like any other great open source project nowadays. Now, I have to confess that I ended up forwarding some RC releases maybe a bit earlier, out of sheer habit -- gnome-shell was Dominique, though :~p But as others pointed out, staging all those pieces may take time and we want to be the early birds here when the final release is out. I've been using GNOME 45 since alpha and haven't found any major issues myself. So, I can say the overall quality of this cycle is not that bad. -- Kind regards, Luciano, openSUSE contributor (luc14n0)
Hi Luciano, thanks for your thoughtful reply. On Sun, 2023-09-17 at 13:34 -0300, Luciano Santos wrote:
All true, but while TW is for early adopters, it's not a beta test bed for upstream projects, either. But I understand it wasn't meant to be in this case, so that's fine with me.
For people like myself, who are involved in extension maintenance on the one hand and must rely on a stable desktop environment for getting work done on the other, it would be helpful to have a well-defined and well-documented way of installing GNOME beta/RC releases (or certain subsets thereof) on top of TW, ideally with some weak promise by the TW GNOME team to help out if something goes wrong badly. Permanently installing alpha or beta releases, like you say you do, doesn't work for me. But I surely could temporarily switch to a pre-release desktop for the purpose of porting my extensions, if I could trust that it would probably not fatally disrupt my daily workflows. I've read https://en.opensuse.org/GNOME_repositories [1] but it rather discouraged me from trying. For example, it was not obvious to me whether just updating GNOME shell and mutter from GNOME:Factory (which is possible in terms of hard dependencies) would work or not, and I couldn't convince myself to update the entire desktop, including apps I really rely on. Thanks Martin [1] This wiki page looks rather outdated to me in general. For example, it still talks about the old GNOME 3.x release versioning policy. And the advice to "remove all of the extra and third-party repositories that you are currently using" isn't helpful, either. Yes, I know, it's a wiki and I could change the page myself. But I don't really feel knowledgeable enough for that.
On Mon, 09/18/2023 at 09:18 +0200, Martin Wilck wrote:
Just FYI, I agree. I was speaking about final releases.
For your use case, you could make use of a VM to install GNOME Next[1]. The ISO images are the same as used by the openQA tests[1], so you can take a look at them before deciding to install one of the builds.
Yes, I should take a look there and make sure the content is still valid. Updating some wiki pages is in my ToDo for a long time now. If I just could've have another me :~p 1. https://download.opensuse.org/repositories/GNOME:/Medias/images/iso/GNOME_Ne... OBS: You can append ".sha256" and ".sha256.asc" to attest download integrity. 2. https://openqa.opensuse.org/group_overview/35
participants (5)
-
Frederic Crozat -
Luciano Santos -
Martin Wilck -
Matěj Cepl -
Richard Brown