Re: List ownership

[mcatanzaro]

Thanks Andre.

I'll likely tighten the settings further, to Reject, after a few days 
(at which point we'll need to figure out new procedures for requesting 
freeze breaks), but let's see how it goes.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

List ownership

[mcatanzaro]

Hi,

Whoever this is... please make me the list owner here:



We need to enable moderation, the spam is too much.

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Time to move to Discord...?

[mcatanzaro]

On Thu, Oct 17, 2019 at 7:42 PM, Jordan Petridis  
wrote:
What will happen to the security ML also, it counts for a good 
portion of the spam here. Do we instruct people to open confidential 
issues against the releng repo and/or the corresponding module?


Hm, I feel like most of what we do is just tell people to report a 
private bug against the affected module.


How about a Teams/Security product on GitLab? We can decommission 
security@ and replace it with an autoresponder directing people to use 
GitLab.


We can also create Teams/Release and immediately decommission 
release-team@. We can figure out how to use Discourse later; first I'd 
like to prioritize turning off the mailing list spam faucet.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: New Mutter dependency: Graphene

[mcatanzaro]

Thanks for the heads-up!

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: VTE & Terminal requirement bumps

[mcatanzaro]

Thanks for the heads-up!


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[mcatanzaro]

On Thu, Sep 12, 2019 at 8:59 AM, Emmanuele Bassi  
wrote:

```
If you change anything related to the build system:

 - dependencies
 - build options

then send a message to release-team@gnome.org.
```


Nice, simple, LGTM.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[mcatanzaro]

On Wed, Sep 11, 2019 at 11:04 AM, Jordan Petridis via release-team 
 wrote:

Should we extend this to tweaking/adding/removing meson options?


Good point, yes.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[mcatanzaro]

On Wed, Sep 11, 2019 at 7:48 AM, Emmanuele Bassi  
wrote:

 - the minimum required version of the dependency


Can it be optional if gnome-build-meta has the new enough version 
already?


Or do we not trust maintainers enough for that? :P


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.35/3.36 schedule vs moving Tarballs Due to Fridays

[mcatanzaro]

OK, I've pushed changes to the releng repo.

Here is the wiki page result:

https://wiki.gnome.org/MichaelCatanzaro/ScheduleTest

I haven't tested the ical creation. Andre, can you take over from here?


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: freeze break request: clean up X property in at-spi2-core

[mcatanzaro]

On Sun, Sep 8, 2019 at 10:57 AM, Mike Gorse  wrote:

I don't
think that it would be the end of the world if this fix has to wait 
for
3.34.1, but, on the other hand, it fixes a regression introduced in 
the

3.34 cycle, so I'd lean towards committing it if people approve.


Well the purpose of the code freeze is to avoid introducing unexpected 
regressions. Here we have a known regression, so it doesn't make sense 
to not fix it IMO. Approval +1/2.


Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME 3.33.92 (GNOME 3.34rc2) RELEASED

[mcatanzaro]

On Fri, Sep 6, 2019 at 6:56 PM, Javier Jardón  
wrote:

the final release is scheduled next Wednesday!


Oops, it will really be Thursday, September 12. The release was 
originally scheduled for Wednesday because I'm bad at picking good 
dates. You might still have stale calendar events scheduled for 
Wednesday; please disregard them.



___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.35/3.36 schedule vs moving Tarballs Due to Fridays

[mcatanzaro]

I've been experimenting here:

https://gitlab.gnome.org/GNOME/releng/commit/b8cc54884dfd28d5f18637e2f801e3055a8641ec

And here:

https://wiki.gnome.org/MichaelCatanzaro/ScheduleTest

Changes:

* One fewer week between newstable .0 and the .1, to help Fedora and 
potentially Ubuntu take the .1 release

* Unstable .4 and .91 releases are eliminated to reduce tarball fatigue
* Stable .2 removed too; maintainers should do more stable releases 
whenever needed; I'm already having second thoughts about this, should 
maybe put it back?
* Actual release dates are removed to help maintainers focus on the 
tarball deadlines (and because I'm tired of maintainers releasing on 
Wednesday two days after the tarball deadline)


TODO:

* Add more stable releases to the schedule? I originally had tarball 
deadlines on here for 3.34.2, 3.34.3, 3.34.4, and 3.34.5. But we don't 
actually want maintainers to care about these dates, we just want to do 
runtime respins if they have tarballs for us, so I removed them.

* Suggestions?


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Doc team notifications of freeze breaks

[mcatanzaro]

Hi,

Historically, our rules for freezes have required notifying 
gnome-doc-list@ of any freeze breaks. This rule has not always been 
followed (I'm a flagrant violator myself). Since nowadays documentation 
operates on a longer cadence (generally years rather than months), I 
think it really doesn't make sense to have these notifications anymore. 
If there are any recent examples of a documentation change being 
committed within the freeze window in response to a freeze break 
notification, please let me know; otherwise, I don't think this change 
should be controversial.


Also, release team really doesn't need to be involved in string freeze 
breaks (to the extent a string freeze break is not a UI freeze break) 
since the internationalization team is well-qualified to handle these.


This means all freeze break requests can now go to just one place:

* String freeze break requests go to 
* Other freeze break requests go to 

unless you're landing a major UI change with string changes, in which 
case you'll still need separate UI freeze and string freeze break 
approvals.


Hopefully this should make freeze break requests a bit easier.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Second Epiphany freeze break request

[mcatanzaro]

On Thu, Sep 5, 2019 at 6:14 PM, Javier Jardón  
wrote:

One approval for you


Any seconds?


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Third Epiphany freeze break request

[mcatanzaro]

Hi,

Adrian found an integer underflow that breaks the adblocker in 
incognito mode:


https://gitlab.gnome.org/GNOME/epiphany/merge_requests/423/diffs

Would be great to have another freeze exception to fix this.

Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.35/3.36 schedule vs moving Tarballs Due to Fridays

[mcatanzaro]

On Fri, Sep 6, 2019 at 7:02 AM, mcatanz...@gnome.org wrote:
* 12 months of stable releases; this means the schedule will be 18 
months total rather than 6


BTW this was the one remaining topic I wanted to discuss before 
proposing a new schedule.


We agreed at GUADEC on 12 months of stable releases. There are two 
counterproposals, 13 months or 9 months:


* 13 months (Fedora-style) gives an extra month of support period so 
that it's possible to skip a runtime without going outside a support 
period, if you plan ahead to upgrade during the 13th month. This means 
we'd support four runtimes at once during the 13th month: three stable 
runtimes and the unstable runtime. I think it's simpler to plan for 12 
months of releases and just not mark the runtime as deprecated until a 
month after the last release, that way we only ever have to support 
three at once.


* 9 months (Ubuntu-style) has a three-month upgrade window, long 
enough to provide a comfortable upgrade window but short enough that 
everyone knows to look elsewhere for LTS (e.g. to freedesktop-sdk, or a 
hypothetical future RHEL runtime). With this support period, we'd half 
the time have three runtimes to support (two stable runtimes and the 
unstable runtime, during the first three months after a new release), 
and the other half of the time only two runtimes (one stable runtime 
and the unstable runtime, during the three months before the next 
release). We could still do an LTS runtime on a separate schedule if we 
ever decide to do so (e.g. for GNOME 3.36).


An opinions? My vote is 9 months, because I fear we underestimate the 
effort involved in maintaining three different runtimes at once. But I 
will propose a schedule for 12 unless I hear opinions to the contrary, 
because 12 is what we have already agreed on.


Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.35/3.36 schedule vs moving Tarballs Due to Fridays

[mcatanzaro]

In the end, we agreed to use Saturday for the tarball deadlines.

There are other changes to the schedule:

* No more overall release date, except for the stable .0 release. 
We'll have only tarball deadlines on the schedule and the overall 
release will come when it arrives.

* New translator deadline for the .0 release
* 12 months of stable releases; this means the schedule will be 18 
months total rather than 6

* Also need to move tarball deadline announcements a bit earlier

I'll look into these scripts soon.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Second Epiphany freeze break request

[mcatanzaro]

Hi,

Due to some changes in WebKit, some code that could previously be 
reached only once is now run multiple times. So Epiphany needs to be 
more careful about not doing one-time things there, like connecting to 
signals.


This commit:

https://gitlab.gnome.org/GNOME/epiphany/merge_requests/421/diffs

just moves the signal connections to a safer place.

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: Tracker and Tracker-miners

[mcatanzaro]

Looks fine, approval 1/2


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Code freeze break request for GLib

[mcatanzaro]

On Thu, Sep 5, 2019 at 5:08 AM, Philip Withnall 
 wrote:

I would like to make the GLib 2.62.0 release tomorrow morning (Friday
6th) due to being away from the afternoon onwards. Can I get a couple
of approvals before then?


Approval 1/2


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Shell freeze break request

[mcatanzaro]

On Thu, Sep 5, 2019 at 7:45 AM, Emmanuele Bassi  
wrote:

RT approval 1/2.


Approval 2/2


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze exceptions for mutter and gnome-shell

[mcatanzaro]

On Wed, Sep 4, 2019 at 2:21 PM, Matthias Clasen via release-team 
 wrote:
Thanks for the detailed explanations. That helps in judging the 
requests. The middle two MRs are unpleasantly large,
but I'll give you approval 1/2, since they all look carefully done 
and reviewed by the shell team.


Here's approval 2/2


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request to fix gnome-initial-setup

[mcatanzaro]

Approval +1 / 2 for both changes


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: freeze break request: use after free in at-spi2-core

[mcatanzaro]

On Tue, Sep 3, 2019 at 4:04 PM, Mike Gorse  wrote:

I need to fix a use after free in at-spi2-core. Patch attached. Sorry
everyone. Carelessness on my part.


It happens, here's approval 1 / 2


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String & UI Freeze break request for GNOME Shell

[mcatanzaro]

On Tue, Sep 3, 2019 at 1:17 PM, Matthias Clasen via release-team 
 wrote:

Tentatively ok with it, but I left a comment.
And since this has some string additions, please also ask 
gnome-i...@gnome.org for their ok.


It's not great to see this so late, but here's your second +1


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Code freeze break request

[mcatanzaro]

Hi,

I'd like to request code freeze break to merge this fix:

https://gitlab.gnome.org/GNOME/epiphany/merge_requests/419/diffs

It might fix (a) a bug causing various Epiphany features to break, and 
(b) some UI process memory corruption. Should be very low-risk since 
it's only two lines.


Thanks,

Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Hard code freeze break approval plea for Evolution

[mcatanzaro]

On Tue, Sep 3, 2019 at 7:20 AM, Milan Crha via release-team 
 wrote:

It already landed, that's why I initiated the mail/plea here:
https://trac.webkit.org/changeset/249421/webkit


I know, but I don't like it. I think WebKit should revert whatever 
needs to be reverted to get back to its old behavior for 2.26 so apps 
don't have to use the environment variable. The envvar will lead to a 
disaster of apps patching themselves to use this temporary envvar that 
won't work anymore in 2.28, and it could jeopardize our ability to 
update WebKit in Debian. I really don't think it's OK even as an 
emergency workaround.


I know this is a very tricky bug. Let's continue the discussion in 
WebKit Bugzilla.



___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Notes 3.34?!?

[mcatanzaro]

On Tue, Sep 3, 2019 at 5:48 AM, Isaque Galdino via release-team 
 wrote:
Thanks Andre. I've read it again, but I don't see a instruction for 
when we miss a previous release, e.g. 3.33.90. So I'm not sure how to 
proceed.

Thanks.


I would call your release 3.33.92, and then do 3.34.0 next week.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Hard code freeze break approval plea for Evolution

[mcatanzaro]

On Tue, Sep 3, 2019 at 4:24 AM, Milan Crha via release-team 
 wrote:

   g_setenv ("WEBKIT_USE_SINGLE_WEB_PROCESS", "1", FALSE);


-1 from me, even as an emergency workaround (and I do understand this 
is an emergency, with release due next week) I don't think a new 
environment variable is acceptable.


There are other ways to solve this, whether by reverting WebKitGTK 2.26 
to the old single process behavior, or by adding a new API to trigger 
the single-process mode, or by making more extensive changes in 
Evolution. We should continue discussion in 
https://bugs.webkit.org/show_bug.cgi?id=201033.


Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for g-c-c

[mcatanzaro]

Copying the original mail below, because this got stuck in the 
moderation queue:


On Tue, Aug 27, 2019 at 4:17 PM, Gunnar Hjalmarsson 
 wrote:

Hello release team,

I'd like to request a freeze break to allow the merge of:



into 3.34. It completes the fix of



The part in gnome-desktop, including the API which the 
gnome-control-center change depends on, is already in.


The remaining g-c-c change affects the display of certain items in 
the Language widget in Region & Language, meaning that for instance 
the item


Serbian Serbia

which actually refers to the latin locale will instead be shown as

Serbian (Latin) Serbia

to distinguish it from the cyrillic locale which will keep being 
shown as


Serbian Serbia

The g-c-c change does not add any new strings to be translated - that 
has already be taken care of in gnome-desktop.


The merge request has been reviewed and otherwise cleared by Robert 
Ancell.


Thanks for your consideration!

--
Cheers,

Gunnar Hjalmarsson



___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Feature freeze break request for Sushi

[mcatanzaro]

In that case, approval 1 / 2.

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for g-c-c

[mcatanzaro]

Approval 1 / 2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Feature freeze break request for Sushi

[mcatanzaro]

On Tue, Aug 27, 2019 at 12:45 PM, Cosimo Cecchi via release-team 
 wrote:

The two merge requests ([2] and [3]) have been reviewed by Carlos here
at GUADEC and should be ready to go in case the feature freeze break 
is

granted.


[2] looks OK for a freeze break, but [3] seems extensive. Are you 
really confident that the chances of a regression (e.g. introducing a 
new crash related to the signals) are low? I'm not sure the quality 
improvement from this MR outweighs the chance of regression?


How sad would you be if I suggest deferring this to 3.36? I'm not 
opposed to approving a freeze break if you think it's important, but I 
do see reason to hesitate.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Four-in-a-Row board drawing fix

[mcatanzaro]

On Wed, Aug 21, 2019 at 5:38 PM, Arnaud Bonatti via release-team 
 wrote:

I’ve an easy but imperfect fix, that I’ve pushed on
arnaudb/fix-board-drawing [1]. It’s just calculating the board size
depending on the tile size, and not the opposite. Problem is, that
makes the board a bit jumping during such a resizing. So, is that ok,
at this point of the cycle, to push an imperfect fix like that one, or
not?


IMO you can do whatever you prefer.

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Release Team presentation at the GNOME Foundation AGM

[mcatanzaro]

We'll definitely have somebody present. (If no other volunteers, I'll 
do it.)


It's probably too late to expect slides though.

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Bump release date for 3.34 from 9/11

[mcatanzaro]

I've modified the schedule here:

https://wiki.gnome.org/ThreePointThirtythree

And here:

https://gitlab.gnome.org/GNOME/releng/commit/a682bb24a0d9c46141c003b88ccb5dc8508e4027

Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Bump release date for 3.34 from 9/11

[mcatanzaro]

Oops, how about switching to September 12 instead? I don't see any 
compelling need to stick to the usual Wednesday date.


Andreas, Matthias, sound OK?

Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Some nigthly flatpaks are failing to build

[mcatanzaro]

On Fri, Aug 2, 2019 at 5:51 PM, Michael Gratton  wrote:
Is there any way to get notification for build failures here? I 
frequently don't end up seeing the build failures. Email sent to 
people listed in the project's DOAP maybe?


Unfortunately there's currently no way to be notified of build failures.

Until there is, I think that means there is no expectation that 
projects actually build. :)


Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME 3.33.4 unstable tarballs due (responsible: jjardon)

[mcatanzaro]

Hi,

This release will be delayed, probably until next week. We're still 
working out problems with dependencies.


Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME 3.33.1 RELEASED

[mcatanzaro]

On Fri, Apr 26, 2019 at 2:43 AM, Samuel Thibault 
 wrote:
I guess I am missing something in the process of releasing a version? 
Or

is accerciser perhaps just not part of a desktop package set?


Only GNOME core elements are included in the release. accerciser is in 
world, not core.


Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: FYI: vte 0.56.2 + No more ftp tarballs

[mcatanzaro]

I think for the time being, the practical consequence is that we'll no 
longer update vte in our flatpak runtimes, until we make changes to our 
release infrastructure to support this. (Which we've been considering 
doing for a long time anyway; we seem to have consensus that in the 
long term we'd like to move to using git tags instead of tarballs.) 
Anyway, we're not there yet, and we won't spend special effort to 
handle vte and gnome-terminal manually.


The recommended way to generate tarballs with meson is 'meson dist'. It 
is much easier than with autotools.


On Thu, Apr 25, 2019 at 11:54 PM, Tristan Van Berkom via release-team 
 wrote:

  * If I understand correctly, I might be wrong, but I think gitlab
creates tarballs on the fly instead of persisting them in
permanence.

I raise this because I don't know with certainty that gitlab
tarball creation is reproducible (in the bit-for-bit sense).

This could mean that an upgrade of our gitlab or it's
dependencies, can potentially result in the same tarballs being
offered up but no longer matching the checksums as before.


This has actually caused problems for release team in the past with 
GitHub tarballs, because the checksums for "old" tarballs actually have 
changed on us before when GitHub changes how tarballs are compressed. 
So with GitHub, the autogenerated tarballs are sadly not suitable for 
use as releases. But you can still separately upload a stable tarball 
for your releases that will appear on the releases page. That requires 
extra work, of course.


I'm not sure about the situation with GitLab, but I assume it is 
similar.



This sounds like a good idea. In particular, to address all the
worries you listed above, I think the easiest and safest short-term
solution would be to create a script which automatically fetches the
tarballs from git for newly appearing tags (for specified versions
only, e.g. vte >= 0.57.0), and pushes them to the FTP area via a
scripted "ftpadmin install" or alike. Does it sound feasible?


I think we should discuss with release-team regarding the best 
technical path forward; ideally that would not involve adding news 
steps to the release process.


Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Welcome Jordan!

[mcatanzaro]

Hi,

A little while back we approved asking Jordan (alatiera) to join the 
release team. At the time, he declined, but now he's willing to join 
under the time-honored rule "just keep doing the same stuff you're 
already doing." Since we all approved his joining quite recently and I 
assume this remains uncontroversial, I've added him to 
ReleaseTeamGroup. Welcome, Jordan!


Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Unauthorized translation changes in dconf-editor

[mcatanzaro]

Please keep gnome-i...@gnome.org CCed

On Mon, Mar 18, 2019 at 5:02 AM, Arnaud Bonatti 
 wrote:

Hi Jeremy and Michael, hi release-team,

2019-03-17 17:01 UTC+01:00, mcatanz...@gnome.org 
:

 I see:

 
https://gitlab.gnome.org/GNOME/dconf-editor/commits/maintainer-only-3-32/po


 which seems pretty excessive. You probably wouldn't be very happy if
 translators starting introducing unexpected changes outside of po/,
 right? In the same way, the translators would prefer you to not make
 changes under po/.


That’s my role as a maintainer to ensure that the product that is
taggued as stable does not look broken.

If translations are breaking the application layout, by translating
the word “Translators” as something crediting translators on a 
long
multiline string (the said “translator-credits” string from the 
About

dialog), it’s my role to not tag a stable release without these
translations fixed.

If a translation contains a web link to what is currently an
hypnotherapist website, it’s my role to remove that link before it
hits the stable release. Even if I didn’t had the time to join the
translator or its team to fix it in l10n. (Yes, it’s a true story. 
Not

a big issue, but a real life one.)


 Why is this necessary? They can't maintain their translations if you
 have your own separate translations that never make it into
 l10n.gnome.org.


My goal is of course to upstream these changes is l10n, not to
maintain a out of tree patchset indefinitely.

But this upstreaming takes time: sometimes translators do not answer
(see 
https://bugzilla.gnome.org/buglist.cgi?quicksearch=product:l10n%20dconf-editor

for long-time bugs without answers), sometimes translators take time
to understand the problem, and I have to tag a stable release by the
time.

But that should not be a surprise if the last commit before the 3.32
dconf-editor release (8d0fa918) is fixing in one translation a problem
I discovered and temporarily fixed in other po files, that’s part of
my work with translators on these issues.

As opposed to what Jeremy Bicha says, my current workflow is not
breaking the translators one; that was not the case with my previous
attempts (sorry again with that). And it is fixing translations for
real life users. And that’s the important part of this story.

Regards,
Arnaud

--
Arnaud Bonatti

courriel : arnaud.bona...@gmail.com



___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Unauthorized translation changes in dconf-editor

[mcatanzaro]

On Sun, Mar 17, 2019 at 10:11 AM, Jeremy Bicha  
wrote:

I am reviving this old thread because it looks like Arnaud never
stopped making his changes. He has created separate "maintainer-only"
branches. He makes his release tags and tarball releases from those
branches. This has continued with the dconf-editor 3.32.0 release from
a few days ago.

This behavior is very disruptive to the translator workflow.
Translators have a very reasonable expectation that their translations
(as seen in the master and stable git branches and at l10n.gnome.org)
will make it to distros and users without being "fixed" in a hidden
way first.

https://gitlab.gnome.org/GNOME/dconf-editor/tags
https://gitlab.gnome.org/GNOME/dconf-editor/commits/maintainer-only-3-32

Jeremy


Hi Arnaud,

I see:

https://gitlab.gnome.org/GNOME/dconf-editor/commits/maintainer-only-3-32/po

which seems pretty excessive. You probably wouldn't be very happy if 
translators starting introducing unexpected changes outside of po/, 
right? In the same way, the translators would prefer you to not make 
changes under po/.


Why is this necessary? They can't maintain their translations if you 
have your own separate translations that never make it into 
l10n.gnome.org.


Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI/String freeze break request for gnome-boxes

[mcatanzaro]

On Fri, Mar 15, 2019 at 9:53 AM, Alexandre Franke  
wrote:
Thanks for the details you provided, they were helpful in making the 
decision.


Yeah, this seems sufficiently-exceptional to justify the proposed 
changes. r-t approval one of two.



___
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

[mcatanzaro]

On Sun, Mar 10, 2019 at 1:17 PM, mcatanz...@gnome.org wrote:

Hm,

Looks like the .90 is currently scheduled for two weeks before your 
feature freeze, so pushing it back one week, like I suggest, should 
be OK.


The .1 looks tight, though. In our current schedule, we have .1 
tarballs due Monday, actual release on Wednesday (you know tarballs 
won't all work before then), and then Ubuntu final freeze Thursday. 
Good luck? Pushing it back one week, as I suggested, would make that 
impossible. We could put the .1 release three weeks after .0, rather 
than four weeks, to give you at least a chance, but it looks really 
tight regardless. Thoughts?


Ah, I see Andre already released the schedule with my 
previously-suggested changes, which puts .1 the same week as Ubuntu's 
final freeze (Monday tarball deadline, Wednesday release, Thursday 
freeze).


___
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 atk MR!14

[mcatanzaro]

On Sat, Mar 9, 2019 at 8:32 AM, apinheiro  wrote:

So although technically this is an API change, I think that it is
  really small, and the effect would be small, and I would like to
  include this on release .32.0


Hm, did GTK get fixed too? It looks like the answer is no? (I don't see 
any recent commits, nor even a merge request.)


Michael

___
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

[mcatanzaro]

On Sat, Mar 9, 2019 at 4:03 AM, Jeremy Bicha  wrote:

My opinion is that the dates that are critical for Ubuntu are the .90
release (compared with Ubuntu's Feature Freeze) and the .1 release
(compared with Ubuntu's release day).


Hm,

Looks like the .90 is currently scheduled for two weeks before your 
feature freeze, so pushing it back one week, like I suggest, should be 
OK.


The .1 looks tight, though. In our current schedule, we have .1 
tarballs due Monday, actual release on Wednesday (you know tarballs 
won't all work before then), and then Ubuntu final freeze Thursday. 
Good luck? Pushing it back one week, as I suggested, would make that 
impossible. We could put the .1 release three weeks after .0, rather 
than four weeks, to give you at least a chance, but it looks really 
tight regardless. Thoughts?


___
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

[mcatanzaro]

+1 / 2

___
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

[mcatanzaro]

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: g-i freeze break

[mcatanzaro]

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

[mcatanzaro]

+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 Epiphany

[mcatanzaro]

Hi,

I'd like to request a freeze break to fix a crash in Epiphany when 
opening the preferences dialog with certain languages configured:


https://gitlab.gnome.org/GNOME/epiphany/merge_requests/219/diffs

Thanks,

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Hardcode break request: mutter

[mcatanzaro]

On Tue, Mar 5, 2019 at 11:44 AM, Andre Klapper  wrote:

Yes please. r-t approval 1 of 2.


Approval 2 / 2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: [evolution-data-server] UI/string freeze break approval request

[mcatanzaro]

1 / 2 release team


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Update your libhandy submodules (and packages)

[mcatanzaro]

Yeah, a new libhandy release ASAP would be appreciated.

Affected applications:

epiphany
gnome-bluetooth
gnome-contacts
gnome-control-center
gnome-games

I think libhandy has reached the point that it's time to start thinking 
about making it a system dependency so we don't have to enter panic 
mode to update a bunch of different places whenever there's a bug like 
this. (There will be more bugs.)


On Fri, Mar 1, 2019 at 4:06 AM, Bastien Nocera  
wrote:

For the release-team:
Did the definition and acceptance criteria change for external
dependencies? libhandy is a library hosted on a 3rd-party server which
some core applications have a dependency on.


We don't really have any formal rules for external dependencies, I 
think not since the GNOME 2 days.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: pygobject freeze break request

[mcatanzaro]

+1 / 2 release team

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String Freeze Break - totem

[mcatanzaro]

"The source seems encrypted and can’t be read. Are you trying to play 
an encrypted DVD without libdvdcss?"


It's challenging to come up with an error message that provides the 
right level of technical detail for users to be able to fix the 
problem, without confusing nontechnical users. Not sure you hit the 
right balance here; it sounds jargon-y.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Boxes | Feature Freeze

[mcatanzaro]

It's getting kinda late in the cycle for changes like this, but it 
doesn't look like too much code. I'll give +1 of 2 release team.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Seahorse - String freeze break

[mcatanzaro]

Oops! +1 / 2 release team

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Feature freeze request - reversion of adaptive shell in GNOME Control Center

[mcatanzaro]

On Wed, Feb 20, 2019 at 9:57 AM, Robert Ancell via release-team 
 wrote:
I'd like to request a change [1] in GNOME Control Center to disable 
the adaptive panel feature. This is due to it introducing some bugs 
[2] and not all panels being updated in time for 3.32. The feature 
will return in 3.34.


+1 of 2, release team

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Music freeze break request

[mcatanzaro]

On Sat, Feb 16, 2019 at 9:02 PM, mcatanz...@gnome.org wrote:

 I like what Music is doing, +2.


To be clear, that's 2/2 release team.

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Music freeze break request

[mcatanzaro]

On Fri, Feb 8, 2019 at 10:56 AM, Emmanuele Bassi via release-team 
 wrote:
Thank you for the clarification; in one of the issues you linked I 
saw the error screen with a GDBus blurb and I got worried. :-)


On Fri, Feb 8, 2019 at 5:15 AM, Emmanuele Bassi via release-team 
 wrote:
Are we really showing a GDBus error message in a landing screen aimed 
at newcomers? Because that would be an immediate -1 from me.


Ciao,


Er well those are screenshots of Photos, not Music. I like what Music 
is doing, +2.


CC: Rishi for the Photos issue. Complaint is that these screenshots:

https://gitlab.gnome.org/GNOME/gnome-photos/merge_requests/85

Should look more like these ones:

https://gitlab.gnome.org/GNOME/gnome-music/merge_requests/335

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Epiphany freeze break request: incognito mode tab style

[mcatanzaro]

On Mon, Feb 11, 2019 at 3:44 AM, Javier Jardón  
wrote:

Thanks for the screenshots

1/2 for release team


Anyone else?

Feels like cheating to give the second approval myself.

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: System Monitor Freeze Break exception

[mcatanzaro]

+1 of 2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: g-c-c display panel UI freeze break request to closer match the 3.30 interface

[mcatanzaro]

+1 of 2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: gnome-software string freeze break request

[mcatanzaro]

On Fri, Sep 14, 2018 at 8:08 AM, Matthias Clasen via release-team 
 wrote:

I asked for this, so +1 from me.


+1 from me as well. You still need two translator approvals.

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Release team involvement

[mcatanzaro]

On Tue, Sep 4, 2018 at 12:21 PM, Olav Vitters  wrote:

Hi all,

Over the last few years I haven't contributed much to the release 
team.
It's time to come to the conclusion that it won't change and it's 
better

to leave the team. I hope clearly acknowledging this ensures there's
room for others to take over.

Thanks for all the nice meetings over the various years!


Thanks for your years of service. :)

Hope to see you around at future GUADECs; we missed you this year.

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 gnome-shell

[mcatanzaro]

I'm nervous about this one for three reasons:

* It's gjs, so any subtle flaw in this changeset could cause entire 
functions to be skipped over
* We're two days before the tarball deadline, so there's really no 
time left to notice if any such flaws were to sneak in

* It's also drag-and-drop code, which is tricky to get right

I would have given +1 to this if requested earlier this week, but at 
this point I'll be quite cautious and suggest committing immediately 
after 3.30.0, so that it has a couple weeks to bake it git before 
3.30.1, just in case.


I'm happy to see the invalid access warnings will be fixed. Almost as 
happy as I would be to see tweener fixes. :P


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Code freeze break request: backwards compatibility fix

[mcatanzaro]

Looks like this is important. Approval 1 of 2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI Freeze Break Request for GNOME Initial Setup

[mcatanzaro]

I'll give a hesitant +1 here. (You also need a second approval.)

* Please consider Will's concern about the network appearing to 
disappear after it's selected. That doesn't seem like a great user 
experience.


* Use of NetworkManager in gnome-initial-setup is a known cause of 
crashers in the past, and there's not really any way to recover the 
first boot experience after that happens. So be careful.


But the benefits do seem worth the late freeze break.

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Tracker (+miners) 2.1.x is the stable series for GNOME 3.30

[mcatanzaro]

On Tue, Jul 24, 2018 at 5:05 AM, Carlos Garnacho  
wrote:

Hmm, I see 2 ways to make that happen:
- As usual, bump by 1 during unstable, bump by 1 for .0. The first
bump may make sense (depends on whether there's actual API additions,
tending to be scarce in Tracker), but the second bump would be rather
artificial as there'd be no API additions or substantial modifications
at the time.
- Bump to next even number directly, suffix versions by "-alpha.X" or
somesuch to convey they're pre-release. (we should probably do this
even if bumping by 1)

Reading point 7 in semver.org, of these two I find the second to fit
better as there's no minor bumps without actual changes involved, but
it's maybe a bit late for it now. If the R-T vastly prefers to avoid
the confusion, I have stuff in the queue I can rush this cycle to make
a 2.2 that'd make all of us happy for now.


Without speaking for the entire release team...

Either of those possibilities would be OK, but the first seems more 
natural to me. I'd see it as a modification of semantic versioning to 
conform to the expectations of our users and distributors.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Tracker (+miners) 2.1.x is the stable series for GNOME 3.30

[mcatanzaro]

On Mon, Jul 23, 2018 at 6:45 PM, Carlos Garnacho  
wrote:

I might send more reminders in the future whenever it might get
confusing, but changes like this within the cycle apply anytime in the
future too. How semver and gnome cycles will be made to fit neatly is
TBD, but rest assured there will be a 2.x series in time for freezes
and stabilized with it. 2.1.x will be it for 3.30.


You could do semantic versioning (which has clear benefits) without odd 
minor versions (which is going to be super confusing), surely?


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME 3.29.3 unstable tarballs due (responsible: mcatanzaro)

[mcatanzaro]

On Thu, Jun 14, 2018 at 8:02 PM, Federico Mena Quintero 
 wrote:

This:

http://ftp.gnome.org/pub/GNOME/teams/releng/3.29.2/versions

has librsvg 2.40.20, which is the unmaintained series.  How can I
change it to 2.43.0 for the development release?  I'd really like to
get some testing there.


We discussed this earlier today on IRC. We need to resolve these two 
issues:


https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/100
https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/24

Once we have Rust working, then updating librsvg should be 
straightforward.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Allow gnome-build-meta notifications from gitlab-issues@ ?

[mcatanzaro]

On Sun, Jun 3, 2018 at 11:14 AM, Andre Klapper  wrote:

Shall we allow them by default or will this be too much noise?


The goal is to use release-team@ to assess whether it will be too much 
noise for desktop-devel@. I would allow them for release-team@, for 
sure, because the entire release team should know when the build is 
broken. After a few weeks, we can discuss whether we should send them 
to desktop-devel@ instead. And if we think it's too much noise even for 
release-team@ (which it shouldn't be), we can always turn them off.


I got the idea from Didier's Foundation board candidacy announcement:

"I think ensuring that breaking the general build is something that is 
immediately seen by the whole community as a read flag [...] is the 
next major step in that direction."


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: New module in GNOME: gnome-internet-radio-locator

[mcatanzaro]

On Mon, May 21, 2018 at 1:16 PM, Ole Aamot  
wrote:

What else do I have to do to mark the module
gnome-internet-radio-locator for release in
GNOME 3.29.2 unstable?


Hi Ole,

For GNOME 3.28, we severely downsized what we release to just a few 
core GNOME apps and dependencies. The motivation behind this change was 
to reduce the amount of software that the release team was responsible 
for (it was just too much). Anyway, that more or less corresponds to 
[1] and dependencies. Everything else was moved off to the world 
element [2].


It's possible that we could revisit this change! But as things stand, 
I'd invite you to add gnome-internet-radio-locator to the world element 
instead. This doesn't require any approval, since world doesn't get 
officially released by release team. Just add an element file under 
elements/world, add it to the list in world.bst, and verify that it 
builds successfully. Feel free to either push directly or open a merge 
request, as you prefer.


Hope that's OK,

Michael

[1] 
https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/core/meta-gnome-core-utilities.bst
[2] 
https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/world.bst


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re:

[mcatanzaro]

Hi Leslie,

We received this from you earlier today. I haven't clicked the link. 
Was this a virus or something?


Michael

On Wed, May 16, 2018 at 5:21 PM, Leslie S Satenstein 
 wrote:

hi Release



https://goo.gl/BMt54J



Leslie S Satenstein


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Post release branching ?

[mcatanzaro]

+1
___
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 libsoup

[mcatanzaro]

On Mon, Mar 12, 2018 at 5:32 AM, Matthias Clasen 
 wrote:

How about landing it right after the release, aiming for .1 ?


Sure, that seems fine at this point.

___
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 libsoup

[mcatanzaro]

On Sun, Mar 11, 2018 at 11:26 AM, Matthias Clasen 
 wrote:

but nobody ever wants notifications from websites.


Currently, if are signed in with a Google account and click the 
notification bubble on google.com, it takes ages to load, and 
eventually gives up with an error. Please test it. The problem is 
caused because our third-party cookie policy is too strict. Since we 
block third-party cookies by default, we need to follow the lead of the 
only other browser that does so, Safari, and consider only the 
website's base domain and not the full domain when deciding whether a 
cookie is third-party.


This has nothing to do with desktop notifications, which have separate 
permissions to prevent users from becoming annoyed. Google doesn't 
create desktop notifications anyway.


___
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 libsoup

[mcatanzaro]

Hi,

This one would be really nice to land, if we could get a second 
approval. I don't see much point in waiting until the .1 to loosen up 
our cookie policy. Thanks!


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 libsoup

[mcatanzaro]

Hi,

A couple weeks ago, I pushed a patch to make the third-party cookie 
policy in libsoup less strict [1]. I asked Claudio to revert it 
immediately before the code freeze because Ting-Wei found a regression: 
it accidentally caused certain cookies  (cookies with the domain 
property set to a value with a leading period) to be blocked, which was 
not intended.


I've fixed the regression and would like to re-land the patch now. This 
fixes notifications on google.com, so it is a major fix. I'll give 
myself the first approval... will anybody second it?


Thanks,

Michael

[1] https://bugzilla.gnome.org/show_bug.cgi?id=792130

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Disks: Hard Freeze Break Request

[mcatanzaro]

+1 of 2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request

[mcatanzaro]

Hi,

The following commit fixes a buffer overflow in epiphany's tests:

https://git.gnome.org/browse/epiphany/commit/?id=0ad97baa47cd13c955e0873e52cf03b84ad4a620

May I backport it to the gnome-3-28 branch?

Thanks,

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Extra release team meeting?

[mcatanzaro]

No interest in this? No comments and no votes? This is surprising. :(

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Extra release team meeting?

[mcatanzaro]

Hi,

I'd like to propose holding an extra release team meeting soon. 
Normally the one we do once per year at GUADEC is sufficient, but as 
we're currently in the middle of a big transition from JHBuild to 
BuildStream, I think it'd be helpful to review how well this is going. 
There are some ongoing hiccups, and Emmanuele has raised some 
legitimate concerns about our previously-agreed strategy.


Since we now have release team members on three different continents, 
finding a time that works well for everyone is not possible, so please 
be flexible. Any time that can work decently for all of us will be 
quite early for America, and quite late for Korea [1]. I've set up a 
time poll for us at [2] with a few time options that I hope everybody 
can live with. Please use the timezone chooser to avoid timezone 
errors. Note the first time option is 5 AM for me, and the last one is 
midnight for Tristan, so be nice and respond with green whenever you 
can so that we don't have to use one of those time slots.


My suggestion would be to use Jitsi Meet [3], since it's the only open 
source RTC tool I'm aware of that seems to work somewhat reliably. I 
strongly recommend installing Chromium for this; unfortunately, it's 
not as reliable in Firefox, and won't work at all in Epiphany. 
Alternatively, we could just do an IRC meeting.


Does this sound good?

Michael

[1] 
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20180221=605=136=235

[2] https://xoyondo.com/dp/X2YxR9ZvBf2wra8
[3] https://meet.jit.si/

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Updated release wiki page

[mcatanzaro]

Hi release team,

I've largely rewritten this wiki page:

https://wiki.gnome.org/ReleasePlanning/MakingARelease

with the goal of making it much simpler and easier to follow. I've also 
emphasized the process of building the entire core.bst project before 
uploading anything. References to smoketesting are removed because we 
haven't done that in several years.


Feedback welcome,

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: [glib][GDateTime] API and string freeze break request

[mcatanzaro]

On Mon, Feb 12, 2018 at 1:54 PM, Rafal Luzynski 
 wrote:
Thank you. So here I have the feedback from the i18n team, as 
Alexandre said I don't need an approval yet. What about any feedback 
from the documentation and release team? Maybe I don't need an 
approval as well?


You do need two approvals from release-team. This is your first, 
because I assume this change is unlikely to break application unless 
they use the new API.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: How to handle release delay

[mcatanzaro]

On Mon, Feb 5, 2018 at 4:56 PM, mcatanz...@gnome.org wrote:
* Release 3.27.90 next week, and skip 3.27.91. We'd have 3.27.90 on 
February 14, 3.27.92 on February 28, and 3.28.0 on March 7.


Hi,

If there are no objections, I'm going to announce this option.

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

How to handle release delay

[mcatanzaro]

Hi,

On IRC today, Javier and I agreed to delay the 3.27.90 release, since 
today was the tarball deadline and we didn't know how to generate 
tarballs using BuildStream. Now the question is, how to adjust the 
schedule to handle this? We have several options:


* Release 3.27.90 next week, after a one week delay, and 3.27.91 the 
week after, on schedule. But it seems excessive to have two development 
releases one week after the other.
* Skip 3.27.90. Release 3.27.91 on schedule. This was Javier's 
proposal in IRC. Downside is that we go an extra week without a 
release; I think it's been more than long enough already since the last 
release.
* Release 3.27.90 in two weeks (when 3.27.91 was scheduled) and skip 
3.27.91. This is exactly the same as the second option, but I like the 
version numbers better.
* Release 3.27.90 next week, and skip 3.27.91. We'd have 3.27.90 on 
February 14, 3.27.92 on February 28, and 3.28.0 on March 7.


All the options seem OK to me, and whatever we choose does not really 
matter very much, but I wanted to ask here first rather than 
unilaterally pick something myself. So please speak up if you have a 
preference. I've ordered them in reverse order of my own preference, so 
if nobody says anything I'll go with the last option.


Keep in mind that the last release was 3.27.3; we completely skipped 
3.27.4, so it's already been almost two months since the last release. 
(Next time it would be better to ask for help, rather than skip a 
release entirely, but it's not a big deal, and anyway, maintainers 
understand this is going to be a much rougher cycle than usual for us.)


Cheers,

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Renaming gnome-tweak-tool to gnome-tweaks?

[mcatanzaro]

On Wed, Jan 10, 2018 at 8:25 AM, Jeremy Bicha  wrote:

Andrea wanted to make sure that the Release Team was ok with this
renaming, so I'm emailing here.


Seems fine to me. I trust you'll take care of whatever breaks as a 
result.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: librsvg 2.42.0

[mcatanzaro]

Hi Federico,

Can you clarify if you're going to stick to even/odd stable/unstable 
numbering, or if distros should now take every release as a stable 
release? You've previously advised that distros move to 2.41, so I 
assumed you were no longer using stable/unstable numbering. But now I'm 
not sure. :)


As long as the latest version is a 2.42, it doesn't matter, but as soon 
as you release a 2.43 then we'll need to know whether to tell distros 
to package it or to wait until 2.44.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.26 retrospective

[mcatanzaro]

On Wed, Sep 20, 2017 at 4:50 AM, Allan Day  wrote:
Extend the UI freeze (or create a freeze period for major UI changes) 
and require that breaks get design approval.


What would extending the freeze accomplish? We already have a long UI 
freeze (five weeks). Wouldn't extending the freeze just make it harder 
to land changes? In general, we've been operating under the assumption 
that making freeze breaks easy to obtain will usually result in a 
higher-quality release, so I'm surprised by the request to make it 
harder to get a freeze break.


Why should UI freeze breaks require design approval? I'm not aware of 
any instance of us approving a freeze break that introduced a 
controversial design change. Do you have an example of a freeze break 
that you wish we had not approved? I think it's reasonable to require 
design team approval if you want to add this requirement, but there is 
no design mailing list so designers will have to follow the 
release-team list if we take this route. I'm not sure it will really be 
beneficial, though: I suspect you'll find yourself needing to approve a 
bunch of pretty mundane requests, and adding another point of failure 
will probably not please module maintainers.


Make it clear at which point UI freeze breaks will no longer be 
accepted.


Hm, I think it's better to handle these on a case-by-case basis, but in 
general:


* A big new feature that introduces lots of new code is only likely to 
be accepted at the very beginning (the first week or two) of the freeze 
period. This is because features like this are pretty much guaranteed 
to introduce a big crop of new bugs, no matter how carefully-developed.
* Significant, noticeable UI changes are not likely to be accepted 
during the final week.


But we can and should make exceptions when appropriate. E.g. in the top 
bar transparency case, I thought it made sense to revert back to our 
previous behavior, even though the request came in quite late. Or if a 
feature is long-awaited and very important, maybe it makes sense to let 
it slip in later than usual. The entire process is for seeking an 
exception anyway. We also consider how stable a particular module is, 
and its release history. If the module has a track record of rarely 
introducing new bugs (e.g. gedit is always rock-solid) then it's more 
likely to be safe to grant an exception. Or if the module has a track 
record of making regular development releases throughout the release 
cycle, then it has had more people testing it in rawhide and 
GNOME:Factory and is also a better candidate for a freeze exception.


Give marketing a say in whether UI freeze breaks are accepted. (And 
find someone other than me to take responsibility for this!)


Is this in reference to the nautilus freeze break request? I don't 
think we want to allow major UI changes late in the cycle just because 
it would make the release notes more interesting. This is the only 
recent case that I remember of a UI freeze break being denied: in 
general, it's quite easy to get a freeze break because you only have to 
convince two release team members. In this case, it was a pretty clear 
"no" IMO because it required lots of new code but was not at all 
urgent: exactly the sort of thing that should be stabilized over the 
course of the next cycle.


The other case that went badly this cycle was the transparency freeze 
break request. I think this was a combination of you taking time off at 
an awkward point right after making the request, leaving nobody to 
ensure it was actually implemented, and possible confusion due to 
Mathias not liking the request and due to me forgetting that Andre had 
given his approval (conditional on docs team's approval, which came 
from Sean). I wrote a mail saying that another approval was required, 
when in fact you already had the two required approvals if we count 
Andre's. But none of the gnome-shell developers actually followed up on 
the request or implemented the change. I think this was mainly a 
coordination issue rather than an actual issue with our process.



Make sure that JHBuild isn't broken, particularly around release time.


Unfortunately some module maintainers do not use JHBuild, and so do not 
notice if their module is broken. E.g. gnome-shell has been broken for 
ages to the point where there is no way anybody could possibly build it 
(some core-dep is at too low a version, I forget exactly what), and 
I've gotten bored of fixing such hugely obvious problems when module 
maintainers don't. I do make sure that the release modulesets always 
build on my computer for the releases that I make, but those are 
tarball modulesets that are different from what developers use. E.g. in 
the gnome-shell case, there was a dependency branch in the master 
branch of some module, which has not been released yet, so the release 
modulesets are fine.


We do have a technical solution to this: replace JHBuild with 
BuildStream. Tristan has 

Yet another freeze break request for Epiphany

[mcatanzaro]

Hi,

I've actually already released Epiphany 3.26.0 yesterday, but [1] was 
reported today and I think it's worth doing an Epiphany 3.26.0.1 
release to get that fix in now. These patches fix the search engine 
management dialog, which unfortunately has been broken for the past 
couple of months. I've already pushed to git since the 3.26.0 is out, 
but I'll hold off on releasing 3.26.0.1 for now unless I receive a 
freeze break approval.


Thanks,

Michael

[1] https://bugzilla.gnome.org/show_bug.cgi?id=787458

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME 3.25.91 released

[mcatanzaro]

On Wed, Aug 23, 2017 at 4:13 AM, Bastien Nocera  
wrote:

The person releasing the GNOME releases usually also spins a new
version of gnome-desktop so that the About section of the Settings has
correct information.

Can you please make sure this gets added to the checklist for 
releases?


Whoops, my bad. This is already on the checklist, but our checklist 
currently contains a lot of obsolete steps and it's out of order, so I 
don't follow it directly and just forgot this time. I was indeed 
supposed to do this. Too late now.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

GNOME 3.25.91 released

[mcatanzaro]

Hi,

GNOME 3.25.91, a late development preview of the upcoming GNOME 3.26 
release, is now available. Please help us test it. If you want to 
compile GNOME 3.25.91 by yourself, you can use the jhbuild modulesets 
available here:


https://download.gnome.org/teams/releng/3.25.91/

The lists of updated modules and changes are available here:

core - https://download.gnome.org/core/3.25/3.25.91/NEWS
apps - https://download.gnome.org/apps/3.25/3.25.91/NEWS

The source packages are available here:

core - https://download.gnome.org/core/3.25/3.25.91/sources/
apps - https://download.gnome.org/apps/3.25/3.25.91/sources/

WARNING! WARNING! WARNING!
--

This release is a snapshot of early 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.25, the full schedule, the official module 
lists and the proposed module lists, please see:


https://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:

https://wiki.gnome.org/Schedule

On behalf of the release team,

Michael Catanzaro



___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Release team mailing list snafu

[mcatanzaro]

Hi,

Due to some overaggressive spam filtering, all mails to 
release-team@gnome.org since early June were dropped. You will need to 
resend your messages. Sorry for the inconvenience.


In particular, take note of this if you submitted a freeze break 
request.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Release schedule change affects GSoC projects

[mcatanzaro]

On Mon, May 15, 2017 at 6:35 AM, Andre Klapper  wrote:

I would not oppose moving "The Freeze" && 3.25.90 release to August
14th. I'd oppose making the entire release schedule (=3.26.0 release) 
a

week longer though, as distributions need to rely on plans.


Hm, I agree that we should not move the 3.26.0 release. I'm OK with 
other schedule changes. But if we move 3.25.90 and change nothing else, 
then we have only one week between 3.25.90 and 3.25.91. I don't think 
there is much value in doing the 3.25.91 release at all in that case.


That said, my experience has been that student projects benefit from 
having the fall/winter release cycle to bake in master, rather than 
trying to sneak them in at the last minute. I know it's very important 
to get projects committed to master, as otherwise they're liable to be 
lost and discarded, but I think the ideal time for that to happen is 
right *after* branching for the fall release. (Of course, students 
should only pass if their work is actually committed to master before 
the end of GSoC, but there's no reason that has to happen before 
branching.) This means less new stuff to showcase for 3.26.0, but also 
more new stuff to showcase for 3.28.0, so that seems fine to me.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.