Re: Hard code freeze break approval plea for Evolution
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: Hard code freeze break approval plea for Evolution
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.
Re: Hard code freeze break approval plea for Evolution
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: Hard code freeze break approval plea for Evolution
Hi Milan,
is there a patch to review somewhere available?
Cannot approve code changes without code. :)
Thanks,
andre
On Tue, 2019-09-03 at 11:24 +0200, Milan Crha via release-team wrote:
> 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.
--
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.
Hard code freeze break approval plea for Evolution
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.
