Re: Freeze break request for Epiphany
On Fri, Mar 6, 2020 at 5:24 pm, Javier Jardón wrote: 1/2 for release team Thanks. Anybody else? ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: mahjongg, issue with ssh key, can't ship release
On Sat, Mar 7, 2020 at 1:06 am, Alberto Ruiz wrote: 3.36.1 is tagged and in master, I still need assistance to release the dist tarball Will do ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: mahjongg, issue with ssh key, can't ship release
3.36.1 is tagged and in master, I still need assistance to release the dist tarball El vie., 6 mar. 2020 a las 17:47, Alberto Ruiz () escribió: > Will go ahead with this tonight, thanks! > > El vie., 6 mar. 2020 a las 3:37, Michael Catanzaro () > escribió: > >> On Fri, Mar 6, 2020 at 1:10 am, Alberto Ruiz wrote: >> > I think the best way forward is to take master, bump the meson.build >> > file to 3.36.1 and issue another release to get the latest >> > translations and let the tagged .0 linger? >> >> Agreed. >> >> > Sorry about this folks. >> > >> > PS: (it occurs to me that we should not allow pushing version tags on >> > commits that are not on a branch?) >> >> Just made the same mistake earlier today with libgnome-games-support. I >> mess this up at least once a year. Automated protection sure would be >> nice >> >> >> > > -- > Cheers, > Alberto Ruiz > -- Cheers, Alberto Ruiz ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
[gnome-notes] Created branch gnome-3-36
The branch 'gnome-3-36' was created. Summary of new commits: 1e896e3... Bump 3.36.0 release ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: More freeze break requests for gnome-shell
Thanks for the detailed explanation of all the freeze requests ; 2/2 for release team On Fri, 6 Mar 2020, 18:41 Michael Catanzaro, wrote: > Thanks Florian. Here's approval 1 of 2 for all nine changes. > > > ___ > release-team@gnome.org > https://mail.gnome.org/mailman/listinfo/release-team > Release-team lurker? Do NOT participate in discussions. > ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: More freeze break requests for gnome-shell
Thanks Florian. Here's approval 1 of 2 for all nine changes. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
[gedit] Created branch gnome-3-36
The branch 'gnome-3-36' was created pointing to: 4769552... Release 3.36.0 ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: mahjongg, issue with ssh key, can't ship release
Will go ahead with this tonight, thanks! El vie., 6 mar. 2020 a las 3:37, Michael Catanzaro () escribió: > On Fri, Mar 6, 2020 at 1:10 am, Alberto Ruiz wrote: > > I think the best way forward is to take master, bump the meson.build > > file to 3.36.1 and issue another release to get the latest > > translations and let the tagged .0 linger? > > Agreed. > > > Sorry about this folks. > > > > PS: (it occurs to me that we should not allow pushing version tags on > > commits that are not on a branch?) > > Just made the same mistake earlier today with libgnome-games-support. I > mess this up at least once a year. Automated protection sure would be > nice > > > -- Cheers, Alberto Ruiz ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
More freeze break requests for gnome-shell
Hey everyone!
Tarballs are almost due (hi Michael!), but there are still a couple of
things we would like to include.
I hope bundling the requests in a single mail is OK:
1. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1068
We currently crash on startup if any of the top-icons extensions is
enabled.
The merge request that addresses the issue is not overly complex,
but still
beyond a trivial one line fix.
However I'd still argue that it is preferable to land, as:
- it has been confirmed to fix the crash, and not crashing is
clearly an improvement
- all code changes are limited to our legacy status icon support, so
it's perfectly
safe for everyone who is *not* using any of those extensions
2. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1069
ibus support is currently broken in the Xorg session. The fix is a
trivial one-liner
("do in the xorg session what we are already doing for xwayland")
3. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1065
If gnome-settings-daemon's xsettings service fails to start, we
currently end up without
X11 support in the wayland session. The fix is again trivial (don't
treat gsd-xsettings
failure as fatal for Xwayland startup)
4. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1110
On multi-monitor systems, popup windows may pop up on the wrong
monitor (or completely
off-screen). The fix should be easy and safe.
5. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
Two small additions to the Extensions D-Bus API. Those are pure
additions, so they have
no effect on any existing users of the API (like the "new"
Extensions app, the browser
integration or Tweaks).
The reason for wanting this in 3.36.0 is that I want to improve(*)
on the Extensions app
in 3.36.1 (and ultimately make it available on Flathub), but it
feels wrong to add new API
in a stable release and rely on it.
(*) all under-the-hood: No UI or string changes
6. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1063
This is a simple request from Ubuntu for a small improvement for
session modes (non-default
GNOME-based sessions like "Ubuntu" or "Classic").
Similar to the above, the reason why I want this in 3.36.0 is that
landing it in 3.36.1 would
open the potential for session modes that are supposed to work on
"3.36", but fail with 3.36.0.
On the other hand it would be sad to delay the improvement for a
whole six months.
Those are the important ones in my opinion. There are a couple more
nice-to-have issues that are low-impact, but have trivial and safe
patches available:
7. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1071
Settings now has a dedicated "Location Services" panel, but the
location submenu
in the shell's top-right menu still launches the "Privacy" panel.
8. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1059
The title of app folders in the overview is hard to read when using
the light theme variant
(like Ubuntu does). Not an issue as far as upstream is concerned,
but the fix is trivial
and safe
9. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1057
The drag handles of the volume/brightness sliders has a small
graphical glitch
at 0; this was supposed to be addressed in 3.35.92, but there's
still a minor
glitch left. Again not the end of the world, but the fix is trivial
and safe
(it's effectively a one-line fix, although the patch hides that a
bit by renaming
a variable)
Apologies for that late flood of requests (they have been piling up
until earlier today).
Regards,
Florian
___
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 Epiphany
1/2 for release team On Wed, 4 Mar 2020 at 21:24, Michael Catanzaro wrote: > > Hi, > > I'd like to merge [1], which fixes a crash when closing Epiphany's > password management dialog that I accidentally introduced in 3.35.92. > > Thanks, > > Michael > > [1] https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/606 > > > ___ > release-team@gnome.org > https://mail.gnome.org/mailman/listinfo/release-team > Release-team lurker? Do NOT participate in discussions. -- Javier Jardón Cabezas ___ 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 glib-networking
2/2 for release team On Fri, 6 Mar 2020 at 11:17, Andre Klapper wrote: > > On Thu, 2020-03-05 at 15:43 -0600, Michael Catanzaro wrote: > > I'd like to request a freeze break for: > > > > https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/116 > > > > which got committed during the freeze period. This just fixes a > > non-void function that lacked a return value in an old fallback path > > when compiling with the OpenSSL backend -- which should be disabled at > > build time almost everywhere -- when using the ancient version of > > OpenSSL in RHEL 6 era. > > > > This surely won't have any impact on anyone using GNOME 3.36, so say > > yes please. :) > > Heh. +1 / yes please. > > 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. -- Javier Jardón Cabezas ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
GNOME 3.35.92 ((GNOME 3.36rc2)) RELEASED
Hi, The second release candidate for 3.36 is here! Remember this is the end of this development cycle; enjoy it as fast as you can, the final release is scheduled next week! The corresponding flatpak runtimes have been published to Flathub. If you'd like to target the GNOME 3.36 platform, you can test your application against the 3.36beta branch of the Flathub Beta repository. You can also try the experimental VM image, available here for a limited time only: https://gitlab.gnome.org/api/v4/projects/456/jobs/artifacts/gnome-3-36/raw/image/disk.qcow2?job=build-gnome-core-x86_64 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.35.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.35.92/gnome-3.35.92.tar.xz The list of updated modules and changes is available here: https://download.gnome.org/core/3.35/3.35.92/NEWS The source packages are available here: https://download.gnome.org/core/3.35/3.35.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.36, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.36 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 Cabezas GNOME Release Team ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
[simple-scan] Created branch gnome-3-36
The branch 'gnome-3-36' was created pointing to: 2e3793f... Releasing 3.36.0 ___ 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 glib-networking
On Thu, 2020-03-05 at 15:43 -0600, Michael Catanzaro wrote: > I'd like to request a freeze break for: > > https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/116 > > which got committed during the freeze period. This just fixes a > non-void function that lacked a return value in an old fallback path > when compiling with the OpenSSL backend -- which should be disabled at > build time almost everywhere -- when using the ancient version of > OpenSSL in RHEL 6 era. > > This surely won't have any impact on anyone using GNOME 3.36, so say > yes please. :) Heh. +1 / yes please. 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.
