Re: [evolution-data-server] Hard code freeze break plea

2020-03-05 Thread Milan Crha via release-team
On Thu, 2020-03-05 at 09:43 -0600, Michael Catanzaro wrote:
> On Thu, Mar 5, 2020 at 4:33 pm, Andre Klapper  wrote:
> > r-t approval 1 of 2.
> 
> Approval 2

Hi,
thanks, I just committed it [1].
Bye,
Milan

[1] 
https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/127dde9233bb62d59ca486a5610c19fde9ed92c7

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


[evolution-data-server] Hard code freeze break plea

2020-03-05 Thread Milan Crha via release-team
Hello,
a user reported an issue [1] in 3.35.92 of evolution-data-server about
missing Google calendars (and tasks), when the account is configured in
GNOME Online Accounts. That's a regression after changes made months
ago.

I can wait with the fix for 3.36.1, but I'd prefer to have the fix
included in 3.36.0, because Google seems to be particularly popular,
thus having not shown calendars for newly created accounts in GOA would
be considered a problem by early adopters.

Thus I'd like to ask: can I commit the change for 3.36.0, please?

The fix is rather trivial [2] and I tested it that it can also fix
already created accounts, thus even users with already created new
accounts will have things fixed silently (after they start patched 
evolution-source-registry).

Thanks and bye,
Milan

[1] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/198
[2] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/198#note_731721

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


[evolution] UI Freeze break approval plea

2020-02-07 Thread Milan Crha via release-team
Hello,
I'd like to ask for a UI Freeze break approval. A user made a patch [1],
which adds an option into Preferences. That's quite minimal change, but
I decided to ask anyway. I'd like to push this into 3.35.91, especially
because it's a contributed change from a user. The change adds also new
translatable strings, for which I'll send a separate notice to the
other list, if it's approved.

The change itself implements an enhancement, which another user asked
for. The change is nothing significant (with respect of code changes),
I do not expect any major side effects dues to it, and if anything
arises, then it'll be quite easy to fix.
Thanks and bye,
Milan

[1] https://gitlab.gnome.org/GNOME/evolution/merge_requests/44

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


Re: Release evolution-rss through GNOME infrastructure

2020-02-02 Thread Milan Crha via release-team
On Wed, 2020-01-29 at 13:56 -0600, Michael Catanzaro wrote:
> Give a day or two before trying, just in case somebody else knows
> some reason why this might not be a good idea.

Hi,
thanks for the info. I went ahead and made the release of 0.3.96, which
is available at:
https://download.gnome.org/sources/evolution-rss/0.3/

I also sent a notice to the distribution-list, in a hope to make
interested parties know. The message is still waiting its moderator
approval, thus I cannot reference it here.

Bye,
Milan

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


Release evolution-rss through GNOME infrastructure

2020-01-29 Thread Milan Crha via release-team
Hello,
for a background: there is an evolution-rss module in GNOME's git. It
was not released for a long time, possibly due to the original
maintainer being gone. I do not want to close/archive it, because it's
used by the users. I prepared a new release and when I wanted to
release it to GNOME's FTP, I realized it was never released through the
GNOME infrastructure. I recalled that the original maintainer had a
special page for its releases. I do not have access to that page. Note,
I'm not going to take over the project, I'm just keeping it running for
the users.

My question: would it be okay to release evolution-rss through GNOME
infrastructure? I guess it will be okay, but I want to be sure.

Just in case, with GNOME infrastructure I mean master.gnome.org and its
`ftpadmin install` tool.

Thanks and bye,
Milan


___
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

2019-09-03 Thread Milan Crha via release-team
On Tue, 2019-09-03 at 05:31 -0500, mcatanz...@gnome.org wrote:
> On Tue, Sep 3, 2019 at 4:24 AM, Milan Crha via release-team 
>  wrote:
> >g_setenv ("WEBKIT_USE_SINGLE_WEB_PROCESS", "1", FALSE);

Hi,
for Andre, that ^^^ is the code. Just that line added into the main.c.

> -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.

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

> We should continue discussion in 
> https://bugs.webkit.org/show_bug.cgi?id=201033.

Yes, yes, it doesn't close the WebKit bug, I thought I'm clear about
that. That's why I call it a workaround.
Bye,
Milan


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


Hard code freeze break approval plea for Evolution

2019-09-03 Thread Milan Crha via release-team
Hello,
after a lengthy investigation around changes in WebKitGTK+ 2.25.x [1],
there was found a way to workaround the problem [2] for now, which
gives time to look for better solution in the future.

The change on the Evolution side is as simple as setting an environment
variable in its main(), to let WebKitGTK+ know the old behavior is
required, something like:

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

This won't break older WebKitGTK+, because it doesn't know about that
new environment variable, and it'll help with the new WebKitGTK+. The
variable addition will be part of 2.25.92 release of WebKitGTK+.
Thanks and bye,
Milan

[1] https://bugs.webkit.org/show_bug.cgi?id=201033
[2] https://gitlab.gnome.org/GNOME/evolution/issues/587

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


Re: [evolution] String freeze break approval plea

2019-08-26 Thread Milan Crha via release-team
On Mon, 2019-08-26 at 15:02 +0200, Piotr Drąg wrote:
> 2/2
> 
> pon., 26 sie 2019 o 14:39 Daniel Mustieles García via release-team
>  napisał(a):
> > Early in the freeze, so 1/2 from i18n.

Hi,
thank you both, I committed it as:
https://gitlab.gnome.org/GNOME/evolution/commit/d513e5fda82f982d2b6e050c054507e7f7916aab

Bye,
Milan

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


[evolution] String freeze break approval plea

2019-08-26 Thread Milan Crha via release-team
Hello,
a user reported a typo in a translatable string [1]. I can fix it, but
it would break existing translations, even it is visible only in
GSettings, dconf-editor and similar tools. The faulty string had been
added before 3.33.1 release.

Can I correct the string, please?
Bye,
Milan

[1] https://gitlab.gnome.org/GNOME/evolution/issues/592

___
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

2019-08-01 Thread Milan Crha via release-team
On Thu, 2019-08-01 at 10:13 -0300, Isaque Galdino via desktop-devel-
list wrote:
> Notes is failing due to EDS. Once EDS changes to gettext, Notes
> should be fine.

Hi,
from what the Goal page references:
https://gitlab.gnome.org/GNOME/evolution-data-server/issues/77

Long story short: This won't happen (any time soon). If you have any
flatpak/CI/whatever, which depends on evolution-data-server to be built
too, then include intltool in the Flatpak manifest for it.

I'm sorry.
Bye,
Milan

___
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

2019-03-01 Thread Milan Crha via release-team
On Fri, 2019-03-01 at 15:33 +0100, Andre Klapper wrote:
> On Fri, 2019-03-01 at 07:14 -0600, mcatanz...@gnome.org wrote:
> > 1 / 2 release team
> 
> 2/2 r-t approval

Hi,
thank you all. I committed it [2] for 3.31.92+.
Bye,
Milan

[2] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/df0a219cc

___
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

2019-03-01 Thread Milan Crha via release-team
On Fri, 2019-03-01 at 11:32 +0100, Daniel Mustieles García wrote:
> Is it just an copy-paste URL in a single string? If so, 1/2 from i18n
> 
> ...
> > URL: [ https://accounts.google.com/signin/   ]
> ...

Hi,
the above are two widgets, a label containing "URL:", which is also
marked for localization, and an entry showing actual URL being used in
the WebKitWebView below it, aka the URL itself, in the entry, is
changing during the process of the authentication and is not localized.

I wanted to re-use an existing string for the label, but there was none
suitable in the sources.
Bye,
Milan

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

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

2019-03-01 Thread Milan Crha via release-team
Hello,
I know this is awfully late, but I also believe this has a very limited
impact to all interested parties, including translators, documentation
and users itself.

I'd like to break the UI Freeze in evolution-data-server's
authentication dialog when using OAuth2, by adding URL line into
it [1]. It's only the

URL: [ https://accounts.google.com/signin/   ]

line in [1], which had been added. It's added, because Google requires
it to be there, which kind of makes sense, even for native
applications, though it makes the dialog uglier. The "URL:" text is
marked for localization, but I guess it's no big deal. Neither I think
this dialog is shown anywhere in the documentation (though I can be
wrong).

I do not think it's really necessary to have this done for 3.32.0, the
same as I agree that the timing, even for such small change, is really
bad, but I think it would be nice to have in the 3.32.0. I'd not ask
for it not being of the Google's requirement for it.

Thanks for consideration.

Bye,
Milan

[1] https://people.gnome.org/~mcrha/google-login.png

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