GNOME 2.32rc2 (2.31.92) RELEASED
Hi all! The second release candidate for 3.32 is here! Remember this is the end of this development cycle; enjoy it as fast as you can, the final release is scheduled next Wednesday! We remind you we are string frozen, no string changes may be made without confirmation from the l10n team (gnome-i18n@) and notification to both the release team and the GNOME Documentation Project (gnome-doc-list@). Hard code freeze is also in place, no source code changes can be made without approval from the release-team. Translation and documentation can continue. If you want to compile GNOME 3.31.92, you can use the official BuildStream project snapshot. Thanks to BuildStream's build sandbox, it should build reliably for you regardless of the dependencies on your host system: https://download.gnome.org/teams/releng/3.31.92/gnome-3.31.92.tar.xz The list of updated modules and changes is available here: https://download.gnome.org/core/3.31/3.31.92/NEWS The source packages are available here: https://download.gnome.org/core/3.31/3.31.92/sources/ WARNING! WARNING! WARNING! -- This release is a snapshot of development code. Although it is buildable and usable, it is primarily intended for testing and hacking purposes. GNOME uses odd minor version numbers to indicate development status. For more information about 3.32, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.30 page: https://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: https://wiki.gnome.org/Schedule Cheers, Javier Jardón GNOME Release Team ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break request for GNOME Shell
+1 / 2 ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Freeze break request for GNOME Shell
Hey, I'd like to request a freeze break for a crash introduced by the fractional scaling support that landed in 3.31.92: https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/450 The particular case in the bug report are "Foo-bar is now ready" notifications for windows with no .desktop file, but it's entirely possible for extensions to trigger the same assertion. The merge request only fixes the issue properly for the reproducer we have in gnome-shell, but at least the crash will be addressed for everyone (there'll be empty icons instead). In particular on wayland where we bring down the whole session, this should be an acceptable drawback :) Thanks for the consideration, Florian ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: 3.33/3.34 schedule draft: questions
On Fri, Mar 8, 2019 at 3:34 AM, Andre Klapper wrote: I've put up a draft schedule at https://wiki.gnome.org/ThreePointThirtythree and in https://gitlab.gnome.org/GNOME/releng/commit/6ff90169cc36f0793beaf27fde629cc7118eee6f Problem: GUADEC is very late (end of August) and 3.34 release should be in early September. On the other hand, anyone can branch gnome-3-34 from master early and still hack away on master? Not sure how many people will be happy to create .92 tarballs while being at GUADEC (and someone to do the release)? If you think it's no problem to have the .92 at GUADEC then I'm happy to make the hardcode freeze again only one week (currently two weeks) and have a .4 release again (I currently went only for 3 unstable releases before .90 comes) I recommend we avoid having any sort of release week during GUADEC, so glad your schedule avoids that. But having two weeks between .92 and the final release doesn't seem great, either. And code freeze during GUADEC seems likely to, er, stress our collective willpower. We could move the 3.34.0 release back one week, to September 11. Then we could have: * 3.33.90: August 5-7 * 3.33.91: August 19-21 * GUADEC: August 23-28 * 3.33.92: September 2-4 * 3.34.0: September 9-11 That's one week harder for Ubuntu, but it avoids any conflict with GUADEC, and is actually more in line with our traditional schedule. (I believe we traditionally targeted the third week of the month.) Targeting the first week of March and September is definitely better for Ubuntu and Fedora, and I hope we can try to do that again in the future (we did for 3.30 but not for 3.32), but due to GUADEC it just doesn't work well for 3.34. Michael ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break request for mutter!486
Hey, On Fri, Mar 8, 2019 at 5:22 PM wrote: > > > +1 / 2 > > This new fix is more code, which triggers my "risky last-minute commit" > instincts, but I trust you're proposing it because you think it's safer > than the originally-accepted solution, in light of the "other reported > issues." Thanks! that makes 2/2 with Emmanuele's :). The fix itself could have been more self contained, cleaning up the then pointless vfunc/argument added up a bit. The previous fix solved animations/screenshots, but didn't help for these later problems (running "XWAYLAND_NO_GLAMOR=1 mutter --wayland --nested" and running a x11 app there should reproduce), this one fixes both. Cheers, Carlos > > Michael > ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: g-i freeze break
On Fri, Mar 8, 2019 at 3:15 AM, Andre Klapper wrote: Yes please. r-t approval 1 of 2. andre 2 / 2, go for it. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break request for mutter!486
+1 / 2 This new fix is more code, which triggers my "risky last-minute commit" instincts, but I trust you're proposing it because you think it's safer than the originally-accepted solution, in light of the "other reported issues." Michael ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Freeze break request for mutter!486
Hi!, I figured better doing this here than over IRC... In the end several people agreed at #gnome-shell that https://gitlab.gnome.org/GNOME/mutter/merge_requests/486 may be a better fix for the swapped colors regression. Also accounting that there's been other reported issues around xwayland and drivers without hw accel. The MR undoes the revert that was meant to be temporary, and removes the root of the problem without apparent drawbacks. Sounds good to go? Cheers, Carlos ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
3.33/3.34 schedule draft: questions
I've put up a draft schedule at https://wiki.gnome.org/ThreePointThirtythree and in https://gitlab.gnome.org/GNOME/releng/commit/6ff90169cc36f0793beaf27fde629cc7118eee6f Problem: GUADEC is very late (end of August) and 3.34 release should be in early September. On the other hand, anyone can branch gnome-3-34 from master early and still hack away on master? Not sure how many people will be happy to create .92 tarballs while being at GUADEC (and someone to do the release)? If you think it's no problem to have the .92 at GUADEC then I'm happy to make the hardcode freeze again only one week (currently two weeks) and have a .4 release again (I currently went only for 3 unstable releases before .90 comes). andre -- Andre Klapper | ak...@gmx.net https://blogs.gnome.org/aklapper/ ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: g-i freeze break
On Fri, 2019-03-08 at 09:19 +0100, Christoph Reiter wrote: > Change in question: > https://gitlab.gnome.org/GNOME/gobject-introspection/merge_requests/142 > > https://gitlab.gnome.org/GNOME/glib/merge_requests/711 fixes some annotation > on the glib 2.60 stable branch. Since the annotations are handled through > g-i we'd need to update g-i for this to take effect. > > ptomato said it would be good to get this in before the freeze: > https://gitlab.gnome.org/GNOME/glib/merge_requests/711#note_455030 > > azzaronea said it would be regression otherwise: > https://gitlab.gnome.org/GNOME/gobject-introspection/merge_requests/141#note_454532 Yes please. r-t approval 1 of 2. andre -- Andre Klapper | ak...@gmx.net https://blogs.gnome.org/aklapper/ ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
g-i freeze break
Hey, Change in question: https://gitlab.gnome.org/GNOME/gobject-introspection/merge_requests/142 https://gitlab.gnome.org/GNOME/glib/merge_requests/711 fixes some annotation on the glib 2.60 stable branch. Since the annotations are handled through g-i we'd need to update g-i for this to take effect. ptomato said it would be good to get this in before the freeze: https://gitlab.gnome.org/GNOME/glib/merge_requests/711#note_455030 azzaronea said it would be regression otherwise: https://gitlab.gnome.org/GNOME/gobject-introspection/merge_requests/141#note_454532 ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
