GNOME version in 21.10

Will we stay at GNOME 40 in impish, or will we update to 41 in some cases?

I’m asking with this g-c-c bug in mind, but it would generally be good to know about the plan. In other words: Is it worth the effort to cherry pick 40+ upstream commits to fix bugs?

Ping: @3v1n0, @seb128

5 Likes

Ideally we would have updated to 41 but feature freeze is today and we didn’t really have the resources available for the update. If you want to update some components please do, otherwise we can still request exceptions for selected updates

Thanks for clarifying. I just uploaded a fix of the g-c-c bug I mentioned.

1 Like

Oh they dropped the even/odd scheme, I had completely missed that…

Yes:
… 3.32, 3.34, 3.36, 3.38, 40, 41, 42, 43 …

https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235

1 Like

So does this mean Ubuntu will once again lag behind Gnome versions? 41 brings in some really good updates and improvements, it would be a shame to wait until 22.04 for them. Oh well.

1 Like

Lagging behind GNOME by one version has one major benefit: Ubuntu users are not the early adopters who suffer all the initial bugs. This would only be the second time we’ve done it in recent years but I found it made the release of 21.04 much calmer. So I’ll be happy to see the same for 21.10. Although not in 22.04 because I have grand plans for performance in GNOME 42 so I want to see that in the LTS.

11 Likes

I would argue that it worked well so far, but I understand that 40 has a lot of changes that needs to be implemented by Ubuntu team which has limited resources. It would be nice though, if we are not early adopters, to introduce the new Gnome releases (maybe point releases) during the Ubuntu release life cycle. I don’t like the Frankenstein Gnome in Ubuntu with software from 2 different (or more) Gnome versions.
I would also like to add, that we suffer from bugs anyway. One of those caused by mutter made me change my workflow significantly in 21.04.

We do already introduce point releases (which are intended to be bugfix only) during the release life cycle. Not major releases.

New major releases would be easier to manage if we were a few more months out of phase with GNOME releases, but that’s an unsolvable problem unless either GNOME or Ubuntu shifted their release cycle.

4 Likes

Here’s some additional background for why the upgrade to GNOME 41 was difficult to get into Ubuntu 21.10.

  • Debian 11 “Bullseye” was released Saturday, August 14.
  • Source packages for GNOME 41 Beta were supposed to be complete by August 14 (but GNOME Shell wasn’t released until August 17 and GNOME Settings Daemon wasn’t released until August 28).
  • Ubuntu 21.10 Feature Freeze was Thursday, August 19.

Ubuntu and Debian both benefit a lot by handling most of the GNOME packaging in Debian directly.

Until Debian’s release, Debian Testing was frozen. During the Freeze, major changes are discouraged from upload to Debian Unstable. The Freeze started months ago and happens every 2 years in preparation for new major stable releases of Debian.

Debian has one staging area beyond Unstable called Experimental.

Normally, there are several months after a major GNOME release for packages to be pushed to Unstable and Testing (with staging in Experimental where necessary or for packaging alpha or beta releases).

So on August 15, Debian Experimental was filled with GNOME 40 packaging. Over the following days, many of these packages were pushed to Unstable. But several packages still can’t be pushed to Unstable yet because they involve transitions where several packages must be upgraded simultaneously and those transitions are waiting on either approval from the Debian Release Team or coordination with Debian developers outside the Debian GNOME team.

If we had pushed GNOME 41 to experimental the week of August 15, it would have delayed Debian Unstable and Testing from getting GNOME 40. They would have likely had to wait for GNOME 41 to be ready later in September.

So, there were only a few days to prepare the packaging. The new packaging would have delayed Debian Unstable and Testing users from getting a new GNOME release for weeks. Or our shared packaging would have been much more difficult to manage.

Future

Even without the Debian Freeze, it is stressful and time-consuming to attempt to package a complete major GNOME upgrade in a few days. While Canonical employees mostly work during the week, Debian and Ubuntu volunteers often do their packaging on evenings or weekends.

(It looks like the 21.10 Release Cycle was one week faster than 20.10’s last year.)

I am estimating that the current schedules provide about a week and a half between GNOME 42 Beta and Ubuntu 22.04 Feature Freeze. In the future, I think we need at least that amount of time to complete the packaging, smoketesting, and critical integration work. If a future Feature Freeze date is too early, maybe we could ask for a Feature Freeze Extension in advance.

12 Likes

Thank you for this great insight into the process. It is more clear now what was (is) going on.

2 Likes

I am most curious (if not worried) about Ubuntu Desktop’s general future under the future total design regime of the GNOME Developers. As I came to understand, those many API features and functions now breaking under Gnome 4* and libadwaita are not early days bugs or not yet implemented parts of the new GNOME version. They are by design, on purpose. Visually most notable of course the fact that libadwaita does not honor the platform Gtk theme (and will never do so), just because these GNOME people feel annoyed by the fact that downstream devs take the ‘irreverence’ to change the stylesheets of their apps, aka theming. (I do know that I am not supposed to criticise people on this forum, but I really wonder why on earth the GNOME dev team is speding their days developing Free Software when they hate so much the freedom associated with it).
But on the topic: What will be done to preserve the Ubuntu Desktop’s unique character?
Nothing, i.e. ship with an essentially vanilla GNOME Shell in the future?
Or hack libadwaita so that it uses Yaru’s stylesheets instead?
Or revive Unity?
Or switch to another DE that isn’t dependent on GNOME?
Or…

3 Likes

Great information, thanks Jeremy!

1 Like

I’m pretty disappointed that Ubuntu will be half a year out dated again

I would much rather the Ubuntu release be slightly delayed

Feature wise being outdated isn’t too big of a problem, but the performance improvements are very important

1 Like

Welcome! But I think that’s off-topic in this thread. You can start a new topic in the Desktop category for that discussion.