If GNOME 48 does make it in, what is the current status on X11 for 48? It's rather unclear right now since https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/99 is still open (and locked from further commenting) so I suppose it will still be possible to use an X session until stated otherwise? I want to stay on X for as long as possible, so I don't want to jump to wayland just yet. I'm not saying this as a wayland vs x11 debate, but rather my needs still need me on X for right now.
On Fri, Jan 24, 2025 at 10:29 AM Matthias Geiger <[email protected]> wrote: > > On Fri, 24 Jan 2025 16:19, Jeremy Bícha <[email protected]> wrote: > >The Trixie Freeze Schedule was released [1] this week, with dates > >later than we had originally expected when compared with the bookworm > >freeze schedule. I think it is possible for us to include GNOME 48 in > >Trixie so this starts discussion about whether to do that. > > > >Calendar Summary > >========== > > > >GNOME [2] > >---------- > >2025-02-01 GNOME 48 Beta tarball deadline. This is also GNOME's UI, > >API, and Feature Freeze. For the past several release cycles, this is > >when we start landing the new GNOME in Debian Unstable (and Ubuntu's > >development release). > >2025-03-01 GNOME 48 RC tarball deadline > >2025-03-15 GNOME 48.0 tarball deadline > >2025-03-19 GNOME 48.0 release: This is a firm announcement/release > >date. Every other date on GNOME's calendar are tarball deadlines with > >the announced release days later. > >2025-04-12 GNOME 48.1 tarball deadline > >2025-05-** GNOME 48.2 tarball deadline. Not announced yet. My guess is > >it's after May 15 though. > > > >Debian [1] [3] > >---------- > >2025-03-15 Transition freeze. Transitions need to be complete in > >Testing by this date. > >2025-04-15 Soft freeze. No new or returning packages allowed into > >Testing after this. > >2025-05-15 Hard freeze for key packages (includes everything that is a > >dependency of gnome) and packages without autopkgtests. We would need > >unblock requests starting here. > > > >Known Transitions > >========== > >1. GNOME Shell/Mutter. The GNOME Shell transition is simpler now that > >it's disconnected from Budgie. I got the new Mutter library package > >through Debian's NEW queue already. Usually, GNOME Shell has > >stabilized enough for extensions at the Beta point but no guarantee. > >We have about 5 weeks to get this transition done from the beta > >tarball release to transition freeze and then one more month for any > >straggling extensions to get back into Trixie. For 47, most extensions > >worked with a simple update to metadata.json and debian/control. > > > >2. glib/gtk/libadwaita. There aren't any issues with these in > >Experimental or in Ubuntu. glib and gtk need the most recent > >development releases packaged though. > > > >3. Rust GTK stack. There will not be a major Rust GTK stack > >update/transition for GNOME 48 in response to distribution complaints > >[4]. So this detail is much easier than it was for the past several > >GNOME releases. > > > >4. Glycin/rust-zbus transition [5]. Matthias Geiger has begun work on > >this. It affects Loupe and GNOME Snapshot but no other GNOME Core apps > >or GNOME libraries. We are waiting for some new rust-gufo* packages > >and rust-jpeg-encoder in the NEW queue. Still some more work needed > >but I think it's in good shape to land by early February if the NEW > >review is quick. Rust crates generally don't have versioned binary > >packages and therefore these transitions are not managed by the Debian > >Release Team currently. > Pretty much everything is staged in exp; and I was able tho build > src:glycin 1.2~alpha with the gufo* packages from NEW, This will land > image editing in Loupe, which will be a great thing to have for trixie. > > >5. evolution-data-server. I already packaged the 48 Alpha release of > >the evolution* stack in Experimental and there is not a soname > >transition this time. > > > >6. Evince. Evince 48 Beta is expected to switch to GTK4. This would > >break everything using the Evince libraries (denemo, gnome-sushi, > >phosh-plugins, sugar-browse-activity, sugar-read-activity). Therefore, > >my plan is to package the new Evince in Experimental for evaluation. > >(I tried to do this for Evince 48 Alpha but the release was > >incomplete, mistakenly leaving out the gtk4 commits [6].) We would > >need a new source package, evince3, to repackage Evince 46, possibly > >only the libraries and not the app itself. Evince doesn't affect the > >rest of the GNOME stack really so we could choose to remain with 46 if > >we want. > > > >7. tracker -> tinysparql and tracker-miners -> localsearch. This is > >leftover from GNOME 47. Fedora and Ubuntu have yet to do this > >transition either. It is not required to otherwise package GNOME 47 or > >48. The renames are waiting in the NEW queue for experimental and then > >we need to verify whether the transition is smooth enough. > > > >8. I still think switching from gnome-terminal to ptyxis would be a > >good idea but I think we are blocked by bash [7] and possibly a screen > >reader regression [8] > > > >Conclusion > >========== > >That's a lot of details but I think we are in good shape to proceed > >with generally shipping GNOME 48. GNOME Shell and Glycin are the only > >core transitions we need. > > > >We should be able to get GNOME 48 RC in before the Transition Freeze > >and 48.1 in before the Hard Freeze. After that, we need unblocks or > >(soon enough) Stable Release Manager approval. > > > What about switching to Papers for 48 ? It's still stuck in NEW; though > I guess we'll want to ship evince since Papers is largely untested ? > > Maybe this could be backported from forky then. > > best, > > werdahias >
