Much appreciated for the info. Certainly the March timeframe is useful so we can have that as a target for Debian.
As an aside - we have already a target list of suitable other apps in the archive so we can drop GNOME apps as they move towards libadwaita.
While I doubt GNOME developers would like it, simply patching the stylesheet in the libadwaita package could be doable to get a theme fitting with ubuntu.
https://gitlab.gnome.org/GNOME/libadwaita/-/tree/main/src/stylesheet
The 5.15 kernel is a Long Term Support kernel, so my guess is that they’d want to stick with 5.15 for the additional support from upstream.
The topic is about GNOME not about the kernel please try to not sidetrack the discussion. In any case the plan is to use 5.15 for the LTS but the oem and hwe variants will get 5.17 as some point.
I am really looking forward to having GNOME Shell 42 in the next LTS.
I also hope that the LTS can adopt as much of the remaining GNOME 42 software stack as possible. I disliked when Ubuntu ships GNOME Apps scattered across three different versions as this sometimes creates a problem with the interoperability or just because I couldn’t use newer features or bug fixes.
If this doesn’t work out, you could always remove mismatching versions from the apt repo and just ship snap/flatpak packages that are updated automatically. Who wants to use a 5-year-old browser (GNOME Web) anyway? 
we have already a target list of suitable other apps in the archive so we can drop GNOME apps as they move towards libadwaita
Fair enough. But it might not be necessary. Let’s see how things go this year.
The new GNOME Console app is also already available in Ubuntu. It’s currently packaged as the old name: kgx
Well, overall an understandable course of action, albeit a bit unfortunate (for some).
At least for me, the question here is: will this possibly create more work than problems over time because you still have to maintain the old versions?
But there is no question if some things (like Yaru for now) don’t work at all - I’m curious how theming will work at all in the future (with libadwaita) or whether theming will have to be reduced to the bare minimum anyway. Like colors and icons. In that case you could go all in with GNOME 42 and use Libwaita… if of course the quality of the apps and programs in GTK4 is good enough. From what I’ve seen, the apps are primarily adjusted, the first point release should take about 3 weeks and is maybe in time for Ubuntu (when reading the PS part).
But I think you have a lot more insight than most of us, it’s clear that each of us would rather have the freshest and newest. Because it’s an LTS release it looks like you have to think a little more conservatively and can’t fix with updates over the next few weeks after the release – because the release ISO has to work flawless.
PS: The time from the GNOME release to the Ubuntu release is also very short, would have recommended just to make some more time here. One week more time for the developers, still a 22.04 release. Don’t think this will throw anyone off course. Most of those who need a stable system wait at least a few weeks with the update anyway, even after an LTS release. Recommended for every release in the future if you build on top of GNOME. IMHO of course
Thanks for the great work!
I would’t mind a future 22.05 and 22.11 release cycle either. Two or three weeks more testing and more time to properly test, fix and adapt.
I understand why this decision was taken, though it is a slight disappointment as someone who typically runs the vanilla GNOME session and who is quite excited about the move to GTK4 and libadwaita.
Slim chance, but just asking to be sure: Is there any chance of an official PPA for the core GNOME 42 apps to be made available to the LTS users at some point after release?
We are not going to work on an official ppa since we limited on resources, but it want new shiny version over stability you should be able to upgrade to 22.10 once it opens and get the updates with the new serie.
Again absolutely understandable ! Will be looking forward to 22.04 nevertheless, cheers.
the approach described by @seb128 is reasonable and thanks for sharing this with us. In short, do you think the full migration/integration with libadwaita will speed up the integration of the latest Gnome releases with the next LTS?
This is true, but we prefer to change something for us in a way that could not work in future.
Also, theming one isn’t the only blocker as it would be shipping software that has mostly been rewritten just before an LTS.
how gnome 42 will work without gtk4?
The desktop team will just not ship GTK4 programs in the main repo because most apps switched to GTK4 just in this cycle (except for the “Extensions” app that switched already last cycle). The GTK 4 apps in main will have to stay at version 41 for this reason. The devolpers fear hat those are not tested enough and might show more regressions than usual. Mutter and Gnome-shell don’t depend on GTK at all (gnome-shell has its own integrated toolkit called “clutter”) and we might see some GTK 4 programs in the universe repo. The ones that will certainly stay at version 41 are Files (Nautilus) and gnome-control-center (Settings). Those will just use GTK 3 as usual (which is installable in parallel to GTK 4).
What parts do you expect will break?
I wrong above, thank you for remove of my misconception
At least Nautilus didn’t finish the switch to GTK4, thus Ubuntu can and will ship version 42. It is in main already. Less diff to upstream is a good thing.
One package that I would love to see updated is libarchive to version 3.6 for it’s increased RAR and ZIP compatibility. But it is not in Debian yet, so probably no dice.
Changelog (February 9th):
Libarchive 3.6.0 is a feature and bugfix release.
New features:
Other notable bugfixes and improvements:
Good day. Are there plans to update mokutil to the latest version 0.5.0 supporting --sbat option?