Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Alexey Proskuryakov via webkit-dev]

+ Keith for visibility

16 апр. 2024 г., в 3:01 PM, Steve Glass via webkit-dev 
 написал(а):

Hi,

Hi, I’m trying to build jsc on my M1 Mac following the instructions at
https://trac.webkit.org/wiki/JSCOnly and https://webkit.org/getting-started/ .
However when I run the built binary it exits immediately with a bus error
which lldb shows to be EXC_BAD_ACCESS.
I'm also trying to build JSC on my M1 Mac and my experience is the exact same 
error as Laurence has reported above.

When I run I get a bus error at the same location in the code:

[27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug 
lldb WebKitBuild/JSCOnly/Debug/bin/jsc 
(lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc"
Current executable set to 
'/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
(lldb) target create Web
Available completions:
WebKitBuild/       
WebDriverTests/    
WebKit.xcworkspace/
WebKitLibraries/   
Websites/          
(lldb) target create WebKitBuild/JSCOnly/Debug/b
Available completions:
WebKitBuild/JSCOnly/Debug/bmalloc/                
WebKitBuild/JSCOnly/Debug/bin/                    
WebKitBuild/JSCOnly/Debug/build-webkit-options.txt
(lldb) target create WebKitBuild/JSCOnly/Debug/bin/jsc 
Current executable set to 
'/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
(lldb) run
Process 86562 launched: 
'/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64)
Process 86562 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=2, address=0x133804000)
    frame #0: 0x00018696f248 libsystem_platform.dylib`_platform_memmove + 
168
libsystem_platform.dylib`:
->  0x18696f248 <+168>: stp    q2, q3, [x0]
    0x18696f24c <+172>: subs   x2, x2, #0x40
    0x18696f250 <+176>: b.ls     0x18696f26c               ; 
<+204>
    0x18696f254 <+180>: stp    q0, q1, [x3]
Target 1: (jsc) stopped.

This is what 'image list' reports at this point:
 (lldb) image list
[  0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0001 
/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc 
[  1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x0001865b /usr/lib/dyld 
[  2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x00010781c000 
/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore
 
[  3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x0001d1096000 
/usr/lib/libedit.3.dylib 
[  4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x0001b06d7000 
/usr/lib/libncurses.5.4.dylib 
[  5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x0001935ae000 
/usr/lib/libSystem.B.dylib 
[  6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x0001935a8000 
/usr/lib/system/libcache.dylib 
[  7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x000193563000 
/usr/lib/system/libcommonCrypto.dylib 
[  8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x00019358f000 
/usr/lib/system/libcompiler_rt.dylib 
[  9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x000193585000 
/usr/lib/system/libcopyfile.dylib 
[ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x0001866a4000 
/usr/lib/system/libcorecrypto.dylib 
[ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x00018678a000 
/usr/lib/system/libdispatch.dylib 
[ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x000186945000 
/usr/lib/system/libdyld.dylib 
[ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x00019359e000 
/usr/lib/system/libkeymgr.dylib 
[ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x00019353b000 
/usr/lib/system/libmacho.dylib 
[ 15] 158A39C2-F9C6-32CA-845B-F1DFB711718A 0x000192a1c000 
/usr/lib/system/libquarantine.dylib 
[ 16] 92A7E10F-1F6C-30D5-9C44-D42352D3A674 0x00019359b000 
/usr/lib/system/libremovefile.dylib 
[ 17] B8B21C7C-4530-3EA2-AB35-BA98B82F33D0 0x00018c0bc000 
/usr/lib/system/libsystem_asl.dylib 
[ 18] E9F1A3B9-AE38-3F4C-BF14-8A6E012AD36C 0x000186639000 
/usr/lib/system/libsystem_blocks.dylib 
[ 19] 49477E07-E77B-332F-B98D-79CA210A866D 0x0001867d5000 
/usr/lib/system/libsystem_c.dylib 
[ 20] 2EA02C23-E13C-39AE-B850-82CEABACE7A6 0x000193593000 
/usr/lib/system/libsystem_collections.dylib 
[ 21] D57D8736-2800-3066-82D4-C433A2DC10C4 0x000191bf6000 
/usr/lib/system/libsystem_configuration.dylib 
[ 22] C9DB5B40-6F90-348A-A518-3ACFB49B39FE 0x000190c34000 
/usr/lib/system/libsystem_containermanager.dylib 
[ 23] 324A6A0A-BBDE-3257-9A75-6A74C85E3430 0x0001931d2000 
/usr/lib/system/libsystem_coreservices.dylib 
[ 24] 8DB1E11F-85AB-3699-AD96-228BE7D8C715 0x000189d5b000 
/usr/lib/system/libsystem_darwin.dylib 
[ 25] 0395D567-DBD9-3F03-A9E0-A0969963A834 0x00024d32a000 
/usr/lib/system/libsystem_darwindirectory.dylib 
[ 26] 4D030E4B-27FC-3C22-8467-A8CAFECA7761 0x00019359f000 
/usr/lib/system/libsystem_dnssd.dylib 
[ 27] 6C663441-D4D5-361C-ABE7-B68D7B6E5B9B 0x00024d32e000 
/usr/lib/system/libsystem_eligibility.dylib 
[ 28] D8AF5585-B9E4-38C0-B48B-CFD5C13DEB82 0x0001867d2000 
/usr/lib/system/libsystem_featureflags.dylib 

Re: [webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

> 18 дек. 2023 г., в 1:44 PM, Michael Catanzaro  
> написал(а):
> 
> On Mon, Dec 18 2023 at 09:16:21 PM +00:00:00, Alexey Proskuryakov 
>  wrote:
>> Same thing - limiting the ability to trivially watch for security bugs that 
>> are initially filed in a wrong component,
> 
> You can currently follow all public activity on the Bugzilla. Are you 
> planning to limit that too?

Are you thinking of scraping Bugzilla? No plans to further limit public access 
at all (we do have some rate limiting already though, to protect service 
availability). I don't think that "it's in principle possible to notice a 
misplaced comment" is equivalent to "let's maintain a way to have every 
misplaced comment delivered to the mailbox of anyone who cares to collect 
those".

Or if there is a similar way to follow all public activity that irreversibly 
emails everything out, then I don't know about it.

- Alexey


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

> 18 дек. 2023 г., в 1:11 PM, Michael Catanzaro via webkit-dev 
>  написал(а):
> 
> On Mon, Dec 18 2023 at 06:07:48 PM +00:00:00, Alexey Proskuryakov via 
> webkit-dev  wrote:
>> I'm still inclined to break the scenario of watching webkit-unassigned. What 
>> do others think?
> 
> I don't think there's any need to disable the ability to watch the Bugzilla 
> account? It shouldn't give anybody access to anything they don't already have 
> permission to see, so what's the point?

Same thing - limiting the ability to trivially watch for security bugs that are 
initially filed in a wrong component, or accidental comments that expose 
something and need to be hidden.

The alternative would be to periodically verify who is watching the account, 
which I don't think is practical.

- Alexey

> Turning off the public mailing list seems good.
> 
> Michael
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

There isn't a lot of difference between unassigned bugs, and those that are 
assigned to people who don't read their bugmail for various reasons. If you 
want to get a decent subset of bugs that aren't being worked on, but not all, 
perhaps a query like this would work for you, 
https://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&chfieldfrom=1d&chfieldto=Now&f1=assigned_to&o1=substring&query_format=advanced&v1=unassigned
 ? This can even go into RSS, to track what's already been read.

Bugs that were filed a while ago and get updates is another query to 
potentially follow, which would have interesting updates and exclude bugs that 
are just opened for PR purposes.

I'm still inclined to break the scenario of watching webkit-unassigned. What do 
others think?

- Alexey

15 дек. 2023 г., в 5:43 PM, Fujii Hironori  
написал(а):

The user watching feature doesn't expose comments that you don't have access to 
the bug.
I'd like to notice that someone commented to unassigned bugs. I don't have to 
check bugs assigned to a developer.

On Sat, Dec 16, 2023 at 8:04 AM Alexey Proskuryakov mailto:a...@webkit.org> > wrote:

My approach would be to also disable the ability to watch the account, for the 
same reason of reducing exposure of accidental postings.

Would you mind sharing your use case? Bugs assigned to webkit-unassigned are 
not a very well defined set of bugs, so perhaps there is another solution that 
works.

- Alexey

15 дек. 2023 г., в 2:25 PM, Fujii Hironori via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > написал(а):


I check it every day. Can I receive the same mails by setting my user watching 
to webkit-unassig...@lists.webkit.org 
<mailto:webkit-unassig...@lists.webkit.org> ?

On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > wrote:
Hello,

Does anybody make use of the webkit-unassigned mailing list? I'd like to 
disable it, to reduce exposure of spam and accidental postings.

- Alexey
___
webkit-dev mailing list
webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> 
https://lists.webkit.org/mailman/listinfo/webkit-dev 
<https://lists.webkit.org/mailman/listinfo/webkit-dev> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> 
https://lists.webkit.org/mailman/listinfo/webkit-dev 
<https://lists.webkit.org/mailman/listinfo/webkit-dev> 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

My approach would be to also disable the ability to watch the account, for the 
same reason of reducing exposure of accidental postings.

Would you mind sharing your use case? Bugs assigned to webkit-unassigned are 
not a very well defined set of bugs, so perhaps there is another solution that 
works.

- Alexey

15 дек. 2023 г., в 2:25 PM, Fujii Hironori via webkit-dev 
 написал(а):

I check it every day. Can I receive the same mails by setting my user watching 
to webkit-unassig...@lists.webkit.org 
<mailto:webkit-unassig...@lists.webkit.org> ?

On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > wrote:
Hello,

Does anybody make use of the webkit-unassigned mailing list? I'd like to 
disable it, to reduce exposure of spam and accidental postings.

- Alexey
___
webkit-dev mailing list
webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> 
https://lists.webkit.org/mailman/listinfo/webkit-dev 
<https://lists.webkit.org/mailman/listinfo/webkit-dev> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

Hello,

Does anybody make use of the webkit-unassigned mailing list? I'd like to 
disable it, to reduce exposure of spam and accidental postings.

- Alexey
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

[Alexey Proskuryakov via webkit-dev]

Hi,

Reviving this old thread, reading it again made me wish for two things:

- a wiki document that describes what we are trying to do, not just a thread 
which patches the proposal with clarifications;

- a discussion of why we can postpone figuring out what to do with containers 
(like Vector or HashMap).

- Alexey

> 23 сент. 2020 г., в 1:54 PM, Jan Korous  написал(а):
> 
> Hi all,
> 
> I am an engineer at Security Tools team at Apple responsible for the tooling 
> support for this effort.
> 
>> On Sep 23, 2020, at 12:34 PM, Darin Adler  wrote:
>> 
>>> On Sep 23, 2020, at 12:18 PM, Ryosuke Niwa  wrote:
>>> 
>>> There are quite a few cases where data members are references but then 
>>> those can also be replaced by a simple member function which retrieves the 
>>> value of the smart pointer member variable and returns a reference.
>> 
>> I think this should be an explicit recommendation in the project of 
>> refactoring to follow these rules.
>> 
>>> For now, a trivial function is defined as a member function defined in the 
>>> class declaration whose definition simply returns a member variable (the 
>>> result of get() or a copy if the member variable is a smart pointer).
>> 
>> That seems like a rule that’s too narrow. I would not want a function to 
>> become non-trivial just because I moved it from being inline within the 
>> class definition to an inline below the class definition in the same header.
>> 
>> This rule worries me a lot right now; it seems like it could result in an 
>> explosion of local variable copies of arguments.
>> 
>>> We probably also need to figure out a way to exempt all lambda functions 
>>> that never get stored anywhere. We have a bunch of helper functions like 
>>> WTF::map which just calls lambdas on each item while iterating over an 
>>> array, etc... and there is no need to create a separate Ref / RefPtr in 
>>> those cases since lambdas are never stored and re-used later.
>> 
>> Does seem important. I am pretty sure I have seen this concept in other 
>> languages. We often try to use const Function& for one type of lambda 
>> argument and Function&& for the other type, but that’s far from complete.
> 
> Re: lambda captures - I think we have two ideas here.
> 
> 1. Allow WeakPtr captures.
> This makes sense to do but it implies we have to add the notion of ownership 
> to the rules. The thing is that WeakPtr is safe on its own (and technically 
> reference-counted) but it can’t be used as a safety measure in the way of 
> RefPtr or Ref since it doesn’t own the memory (not even in a shared manner).
> 
> 2. Allow raw pointer/reference captures.
> This makes sense given you use generic algorithms in the codebase. I will 
> implement a new version of the checker - currently it is still based on 
> simple AST analysis and for this kind of reasoning we’ll need to use symbolic 
> execution in Clang Static Analyzer.
> 
> Thanks,
> 
> Jan
> 
>> — Darin
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Update commit log template to make GNU changelog optional

[Alexey Proskuryakov via webkit-dev]

Hi Michael,

The intention of per-file or per-function comments is to have a deeper 
explanation of code changes, as opposed to overall explanation of what the 
change does at the top. Not every patch needs it, but many do. These are very 
helpful in my experience.

    * Source/WebCore/animation/CSSTransition.h: Use const AtomString& for the

    return value of transitionProperty to cut down on reference count churn.

    Use nameString, moved isCSSTransition to private.


Never heard the phrase "GNU changelog" before! But not sure if they are any 
less relevant with version control than without.

As for stale commit messages, we can probably have some tooling that does a 
more intelligent job, regenerating them while preserving the original comments.

- Alexey

17 нояб. 2022 г., в 3:23 PM, Michael Catanzaro via webkit-dev 
 написал(а):

Hi,

I'd like to remove the GNU changelog from the bottom of the commit messages by 
default. With "by default" I mean people who prefer to use the GNU changelog 
for formatting their commit messages would have to change git-webkit 
configuration to keep using it, and it would go away for everyone else's commit 
messages. I don't see any reason to prohibit the changelogs if really desired, 
but these were designed for an era before version control existed, to explain 
what is being changed rather than why. The freeform commit message that we add 
above the changelogs is usually a better way to explain commits.

(Another disadvantage is it is really easy for the changelog to become stale by 
mistake. When amending commits, you have to look closely at the bottom of the 
commit message template prepared by git-webkit to notice the updated changelog, 
then manually replace the original commit message's changelog. I'm sure we 
commit inaccurate changelogs all the time because we forget to do this.)

Michael


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Nicks in contributors.json

[Alexey Proskuryakov via webkit-dev]

I think that nicks are handy in a couple cases:

1. Finding people on Slack. For this, they would probably need to stay on 
https://webkit.org/team.

2. Bugzilla autocomplete - I type "smfr" and do not need to scroll like if I 
typed "Simon". This could be addressed by switching to GitHub names in 
autocomplete code.

- Alexey

> 24 окт. 2022 г., в 2:13 AM, Anne van Kesteren via webkit-dev 
>  написал(а):
> 
> Heya,
> 
> Now that GitHub needs are addressed through a github field in
> contributors.json and WebKit moved from IRC to Slack, is there still a
> need for the nicks field?
> 
> Based on a suggestion on Slack I'm thinking of removing it from
> https://webkit.org/team/ and I might as well clean up
> contributors.json at the same time.
> 
> Kind regards,
> 
> Anne
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Alexey Proskuryakov via webkit-dev]

Ross, I didn't mean any disrespect.

I absolutely agree that this issue is not about the project supporting multiple 
platforms.

What I disagree with is the statement that omitting includes necessary for 
non-unified build is a mistake, or that it needs to be made visible. Fixing all 
of these is very time consuming, whether it's done pre- or post-commit. In my 
mind, it is a logical conclusion that this shouldn't be done at all, neither 
pre- nor post-commit. The downside is that patches are more likely to break the 
build, but overall it's less work, because only a small percentage of "missing" 
includes will ever cause problems. So, ignoring non-unified build saves work 
over time, and saves the 6 days per month that its maintenance has been costing.

Perhaps that's incorrect, and the cost situation is the opposite? So that 
ignoring non-unified builds is costlier overall? It is a real cost, in 
particular because it sometimes requires fixing issues in unfamiliar code, but 
that cost hasn't been quantified AFAICT.

In other words, the choices are:

With non-unified EWS:
- many patches get rejected for breaking it;
- it's easy for the patch author to add the includes.

Without non-unified EWS, or anyone fixing non-unified build manually:
- a smaller number of patches gets rejected for breaking existing EWS builders;
- it's sometimes harder to fix, because the errors could be in unfamiliar code 
(although how hard can it be to add an include, on average).

Without non-unified EWS, but someone fixes non-unified build manually:
- an even smaller number of patches gets rejected due to missing includes;
- it's a huge investment on the part of those who keep fixing the non-unified 
build.

- Alexey

7 сент. 2022 г., в 6:20 PM, Kirsling, Ross via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > написал(а):

This conversation has had some diverging threads (which is what makes mailing 
list-based communication so difficult), but I'm disappointed that this should 
mean that the crux of the conversation was lost.

There is no such thing as "not maintaining the non-unified build"; there never 
has been. We have covered that this is an *inherent* problem in a unified build 
mechanism and that this would be an issue even if Mac were the only platform. 
The *singular* question at play is whether contributors have visibility into 
the repercussions of their mistakenly omitted includes. The proposal is to have 
a bot to provide this visibility, and Igalia already has one ready to offer. No 
single platform can provide complete visibility because no single platform 
compiles everything, but incomplete visibility would still save a huge amount 
of labor regularly performed by the community.

The fact that this labor can not only be overlooked but outright *defended* is, 
quite frankly, appalling—it is the most disrespectful behavior I've witnessed 
in my time contributing to this community.

Ross

Get Outlook for Android <https://aka.ms/AAb9ysg> 

From: Alexey Proskuryakov via webkit-dev mailto:webkit-dev@lists.webkit.org> >
Sent: Wednesday, September 7, 2022 5:05:40 PM
To: Michael Catanzaro mailto:mcatanz...@gnome.org> >
Cc: webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> 
mailto:webkit-dev@lists.webkit.org> >
Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder
 
I can't speak for everyone, but the reason why I haven't been responding was 
that the discussion went in circles, and didn't address the concerns raised.

There is new evidence showing that maintaining the non-unified build is very 
hard. We knew that from the start, which is why the plan was to not maintain 
it. Seems like this newly posted evidence only reinforces the decision.

- Alexey

> 7 сент. 2022 г., в 10:41 AM, Michael Catanzaro via webkit-dev 
> mailto:webkit-dev@lists.webkit.org> > 
> написал(а):
> 
> 
> At this point I would just go ahead and create the EWS bot. Even if it's not 
> going to be a default build configuration, we're still wasting a bunch of 
> time and effort to keep it working, and the EWS would help fix that.
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> 
> https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!_-YAPcPo_76ayjWZ1XeMQ8GeKGm4GosQLa_S2VyNAFELCChziGVCya-6PVjS2uwD27UxfA_DnSX4FpDUJ7rwqxwrjek$
>  
> <https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!_-YAPcPo_76ayjWZ1XeMQ8GeKGm4GosQLa_S2VyNAFELCChziGVCya-6PVjS2uwD27UxfA_DnSX4FpDUJ7rwqxwrjek$>
>   


___
webkit-dev mailing list
webkit-dev@lists.

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Alexey Proskuryakov via webkit-dev]

I can't speak for everyone, but the reason why I haven't been responding was 
that the discussion went in circles, and didn't address the concerns raised.

There is new evidence showing that maintaining the non-unified build is very 
hard. We knew that from the start, which is why the plan was to not maintain 
it. Seems like this newly posted evidence only reinforces the decision.

- Alexey

> 7 сент. 2022 г., в 10:41 AM, Michael Catanzaro via webkit-dev 
>  написал(а):
> 
> 
> At this point I would just go ahead and create the EWS bot. Even if it's not 
> going to be a default build configuration, we're still wasting a bunch of 
> time and effort to keep it working, and the EWS would help fix that.
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit-changes substitute

[Alexey Proskuryakov via webkit-dev]

Hi,

There doesn't appear to be anything good enough, filed 
https://bugs.webkit.org/show_bug.cgi?id=243793 to track. Please add your use 
scenarios if they are different from what I listed.

I wanted this too, but gave Jonathan incorrect information about importance - 
it seemed like the mailing list only had a few subscribers these days, but 
double-checking that, there are actually many.

- Alexey

> 8 авг. 2022 г., в 7:32 AM, Dan Bernstein via webkit-dev 
>  написал(а):
> 
> Hello,
> 
> Is there some way to receive full webkit commits in email form, similar to 
> the webkit-changes mailing list?
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Add CODEOWNERS to WebKit

[Alexey Proskuryakov via webkit-dev]

It seems like we still need to host watchlist CC service though, to support 
patch workflow - and we'll have separate lists in GitHub and in Bugzilla, 
unless watchlists are reimplemented.

I believe that while there are stale watchlists entries, newer additions are 
valid.

- Alexey

2 июня 2022 г., в 2:19 PM, Jonathan Bedard via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > написал(а):

Porting is possible, but that would be something that would happen, at the 
earliest, a few weeks from now. I does seem to me that the watchlist is out of 
date, so a forced-cleanup doesn’t seem like the worst thing.

Jonathan

On Jun 2, 2022, at 2:21 PM, Chris Dumez mailto:cdu...@apple.com> > wrote:

I’m kind of ambivalent/neutral about this. One question though:

When adopting CODEOWNERS, will our existing watchlists get ported, or will each 
contributor have to modify CODEOWNERS themselves to match whatever was in the 
watchlists for them?

Thanks,
Chris.

On Jun 2, 2022, at 1:12 PM, Jonathan Bedard via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > wrote:

Hey folks,

Yusuke is interested in adding the CODEOWNERS file to the WebKit project (see 
https://github.com/WebKit/WebKit/pull/1137 
 ). There have been some objections 
to this, the two ones I’m aware of:
- WebKit doesn’t assign “ownership” to pieces of code, so the name is 
unfortunate
- The last match “wins”, so if you subscribed to a generic directory early in 
the file, more specific matches would override that subscription

Despite these downsides, I think adding the CODEOWNERS file is good for the 
project for a few reasons:
- It’s a standard natively supported by GitHub, BitBucket and GitLab and will 
be familiar to developers
- File format is more simple than existing watchlist
- Support for groups and individuals
- No need for WebKit to host a service (other implementations of auto-CCing 
would require this)

I intend to work with Yusuke to land https://github.com/WebKit/WebKit/pull/1137 
  and start adopting CODEOWNERS on 
Monday absent objections that folks think overshadow the benefits of the 
CODEOWNERS file.

Jonathan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org  
https://lists.webkit.org/mailman/listinfo/webkit-dev 
 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org  
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Alexey Proskuryakov via webkit-dev]

Hi,

I'm not sure if we have a consensus on whether it is a project goal to keep 
non-unified build working at all times. As discussed last year, setting up 
post-commit bots is a pre-requisite for having EWS, so this part is resolved. 
But proactively maintaining the non-unified build is strictly more work than 
fixing it on demand. So the immediate response continues to be that we 
shouldn't be doing more work when we can do less.

You mention that embedders who build with non-default flags are more likely to 
hit issues. Building with non-default flags would be resulting in missing 
includes for non-unified builds too, do you have an estimate of how much this 
problem grows due to unified builds? How do we decide if everyone is 
responsible for the convenience of downstream embedders?

It sounds like none of actively supported ports builds non-unified by default, 
which I understand from the fact that a special post-commit queue had to be set 
up for that.

Perhaps part of the argument is that even though proactively maintaining the 
non-unified build is more work, this work is somehow easier than fixing builds 
on demand. If so, can you elaborate on why this is the case?


- Alexey

21 мая 2022 г., в 12:10 AM, Kirsling, Ross via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > написал(а):

This is wonderful news—thanks Diego!

Ross

From: dpino via webkit-dev mailto:webkit-dev@lists.webkit.org> >
Sent: Friday, May 20, 2022 9:17:56 PM
To: webkit-dev@lists.webkit.org  
mailto:webkit-dev@lists.webkit.org> >
Subject: [webkit-dev] Deployment of new EWS Non-Unified builder
 Hi,

Last year we started a thread to discuss the possibility of deploying a
new EWS bot that builds WebKit with Non-Unified sources [1]. This thread

explains the technical reasons why a non-unified build bot is desirable.

If you're aware of the problems introduced by unified sources
compilation, skip the next paragraph.

Unified sources compilation consists of merging several source files
together into one big file to improve building times. Usually the same
sources files are grouped together, but compilation flags or downstream
changes can create different source file groups. When that happens, you
may hit a build error. Since unified sources group files together,
missing headers in one file can be satisfied by another file in the same

group. What's happening in WebKit development currently is that source
code that breaks non-unified compilation frequently lands without even
being noticed. The breaks are usually related to missing headers.
Embedders that need to support WebKit builds with different flags or
maintain downstream changes are more likely to hit these compilation
errors.

Last year's attempt to deploy an EWS Non-Unified builder ended up in a
deployment of a post-commit bot plus two workers running in the UAT. It
was actually hard to get the Non-Unified builder working [2], something
that we achieved at the beginning of this year (kudos to Adrián and

Lauro). Since then we have been maintaining the post-commit bot very
closely. There are periods of time where the bot has remained green for
a long period of time.

But lately maintaining the bot green has become harder and harder,
specially due to the big refactorizations that have happened in WebKit
source code lately. The bot very rarely stays green longer than 2 or 3
days without close maintenance. We believe that we all should share the
responsibility of keeping the non-unified build working, and therefore
we want to proceed with the deployment of a EWS Non-Unified builder.

Initially, we'll provide two workers on a modern host with 8 cores
assigned each. We have found this setup faster for most patches than
many of the existing EWS queues, as it only runs a build in non-unified
mode, without test or upload steps. If this were not fast enough, we
would consider increasing the number of workers in the queue. We set up
a page[3] with a rough comparison to the regular (unified) bot and the
build times are pretty similar.

Diego

[1]
https://urldefense.com/v3/__https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30077.html__;!!JmoZiZGBv3RvKRSx!6YGOGRuK21OCDj8_MKm9gtNOYvBg9Ry10BMna8HXDHWUcUpVeDPBeA4QBT-nC3xj3j8wgt_mjpqbrrOsbTOSWjtVsXQ$
 

 
[2] 
https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=226088__;!!JmoZiZGBv3RvKRSx!6YGOGRuK21OCDj8_MKm9gtNOYvBg9Ry10BMna8HXDHWUcUpVeDPBeA4QBT-nC3xj3j8wgt_mjpqbrrOsbTOSqxngQkY$
 

 
[3] 
https://urldefense.com/v3/__https://people.igalia.com/lmoura/web

Re: [webkit-dev] Proposed changes to Bugzilla 'Resolution' categories

[Alexey Proskuryakov via webkit-dev]

> 10 февр. 2022 г., в 12:06 PM, Michael Catanzaro via webkit-dev 
>  написал(а):
> 
> On Thu, Feb 10 2022 at 11:55:56 AM -0800, Brent Fulgham via webkit-dev 
>  wrote:
>> (1) Add a new “Behaves As Designed” option:
>>> This will represent bugs that were filed when the reporter misunderstands a 
>>> feature, or wants behavior that we have considered, but chosen not to allow.
>>> This would be used instead of the somewhat offensive “WONTFIX” or mildly 
>>> offensive “INVALID” resolutions we currently use.
> 
> I'm surprised we don't already have an appropriate status for this, 
> considering how common it is. Calling this NOTABUG would match at least one 
> other major Bugzilla instance, and is nice and short. Alternatively, we could 
> call it EXPECTED BEHAVIOR. BEHAVES AS DESIGNED seems a bit long.
> 
>> (2) Add a new “Platform To Resolve” option:
> 
> Like Simon, I currently use the existing MOVED status to indicate this 
> ("Moved" to external tracker), although it's not a perfect fit if I simply 
> tell the reporter to report elsewhere (in that case, it really means "needs 
> to be moved"). If we want to add another status for this, we should look for 
> a simpler name.


There are two different cases here, which should probably have different 
resolutions.

1. The resolver determines that this is not a WebKit issue, and wants to the 
reporter to file it against the platform. This is generally the most helpful 
thing to do for Apple platforms, because it creates a line for communication 
between Apple and the reporter. Migrating it ourselves may feel like it would 
be best, but in my opinion at least, it's not.

2. The resolver determines that this is not a WebKit issue, and reports it 
against the platform (or finds an existing platform bug report).

- Alexey
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS Non-Unified builder

[Alexey Proskuryakov via webkit-dev]

(Re-sending from correct address)

These points from my yesterday email remain without responses:

1. Cannot have an EWS without corresponding post-commit queue.

2. It doesn't appear like we looked into whether there are any ways to mitigate 
the problem other that this most costly one.

- Alexey

> 30 апр. 2021 г., в 8:43 AM, Darin Adler via webkit-dev 
>  написал(а):
> 
> OK. I acknowledge my view on this is different from the others commenting 
> here, perhaps because of different ideas about what is hard and requires 
> expertise. I won’t stand in the way of changes you want to make. You know my 
> view now.
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS Non-Unified builder

[Alexey Proskuryakov via webkit-dev]

Hi,

Do we have a post-commit non-unified builder? Starting with EWS wouldn't seem 
like a workable plan to me, as breakages would creep in anyway, and it's really 
hard to notice and isolate those from EWS results alone.

Giving all WebKit developers the responsibility to support more build 
configurations, particularly ones that are not required for any shipping 
product, terrifies me. I can see how unpredictable per platform build failures 
when files are added or removed are a downside of our unified builds. This 
doesn't seem like an intrinsic part of unified builds though. Can we do 
anything to make reshuffling the files more controlled, so that build failures 
happen predictably when one is willing to deal with them?

- Alexey

> 28 апр. 2021 г., в 11:45 PM, dpino via webkit-dev 
>  написал(а):
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS queue: Stress Test EWS

[Alexey Proskuryakov via webkit-dev]

Hi,

This issue is tracked as https://bugs.webkit.org/show_bug.cgi?id=225126 


- Alexey

> 28 апр. 2021 г., в 3:23 AM, Manuel Rego Casasnovas via webkit-dev 
>  написал(а):
> 
> Hi,
> 
> The stress test EWS has some issue when dealing with testharness.js tests.
> 
> Every now and then it thinks it's a different type of test and it dumps
> the layout tree, and it fails as the actual result has nothing to do
> with a layout tree dump.
> 
> Actually it dumps an empty layout tree:
> layer at (0,0) size 800x600
>   RenderView at (0,0) size 800x600
> layer at (0,0) size 800x600
>   RenderBlock {HTML} at (0,0) size 800x600
> RenderBody {BODY} at (8,8) size 784x584
> 
> Last example I've seen:
> https://ews-build.webkit.org/#/builders/62/builds/1903
> 
> I guess there might be some timing issue or something like that, as it
> looks like it doesn't even load the test properly before comparing the
> results.
> 
> Cheers,
>  Rego
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Updated Subversion installer for WebKit development on macOS

[Alexey Proskuryakov via webkit-dev]

Hi,

We've posted a new svn installer for macOS to https://webkit.org/build-tools/ 
. It now runs natively on Apple Silicon, and 
the build contains the fix for 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17525 
.

Please let me know if anything doesn't work as expected.

- Alexey___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Alexey Proskuryakov]

> 3 окт. 2020 г., в 2:24 AM, Adrien Destugues  
> написал(а):
> 
> On Fri, Oct 02, 2020 at 07:05:21PM -0500, Michael Catanzaro wrote:
>>> I realize that Gerrit might not integrate at all with hosting the repo
>>> on Github, but has any thought been given to this aspect of the
>>> transition?
>> 
>> That sounds like it would be a significant barrier to contribution, and
>> frankly defeat the point of switching. If we have serious concerns with
>> GitHub's code review functionality (which, again, I'm not familiar with),
>> then we should just use GitLab and have everything in one place. (GitLab
>> accepts GitHub logins via OAuth, both on gitlab.com and self-hosted
>> instances, so the barrier to contributing remains low either way.)
> 
> Gerrit accepts GitHub and other OAuth providers as well, so that's not a
> problem. We have been using this for Haiku code reviews for a few years
> now, and interestingly we got some complaints from people who don't want
> to have a Github account (for various reasons) and won't use our code
> review tool because of that.

What are the reasons why people don't want to have a GitHub account? I wonder 
if that's somehow a different kind of barrier to entry to be concerned about.

- Alexey

> I think the integration referred to was rather in terms of having
> reviews synchronized between Gerrit and Github pull requests, which is
> also possible, but I think if the point is to use Github, it doesn't
> work this way: if your workflow is too different from the standard way
> to use Github, people will still be confused by it and it will still be
> a barrier to contribution.
> 
> I think having to create an account on a website isn't the main thing
> preventing people to contribute anyway? It's more about having to use
> project-specific tools to prepare the patch for submission (in the case
> of WebKit, having to write the commit message in the Changelog file, for
> example).
> 
> -- 
> Adrien / PulkoMandy
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

[Alexey Proskuryakov]

> 19 июня 2020 г., в 1:11 PM, Mark Lam  написал(а):
> 
> 
> 
>> On Jun 19, 2020, at 10:24 AM, Geoffrey Garen > > wrote:
>> 
 On Jun 19, 2020, at 8:04 AM, Geoffrey Garen >>> > wrote:
 
 Can you explain more about what "O3 with no-inlining” is? How does 
 --force-opt=O3 avoid inlining? Would this fully resolve Simon concern 
 about stack traces, or would something still be different about stack 
 traces?
>>> There doesn't exist a way to do this now, but it'd be trivial to add a way. 
>>> I won't claim it fixes all stack traces differences, but I'd think 
>>> compiling using "-fno-inline -fno-optimize-sibling-calls" would get us 
>>> pretty far in crashing stack traces being similar enough.
>> 
>> Sounds good.
>> 
>> I think we should try to refine the proposal along these lines, to minimize 
>> the downsides. I won’t speak for Simon, but for me, being able to ensure a 
>> clear backtrace from a bot would be a big improvement.
>> 
 And again, I think this discussion would get a lot more focused if the 
 change could apply only to JSC code, and not also to WTF code.
>>> I believe Mark's proposal, initially, is just to make JSC do this. So I 
>>> don't see the point of compiling WTF differently. JSC can kick off its own 
>>> build, and run Debug+O3 tests faster than it can run Debug+O0 tests. Given 
>>> people working on JSC want this, and people working on JSC defend these 
>>> tests, and that these test results are more stable (see below), we should 
>>> make this change for JSC.
>>> 
>>> I was trying to convince folks defending non-JSC testing, that they too, 
>>> should want this. I'm not going to pull teeth here. If folks want their 
>>> tests to take ~10x longer to run, they're entitled to make that tradeoff.
>> 
>> Got it.
> 
> I'm of the same mind as Saam.  We want this change for the JSC bots, and from 
> the time measurements I’ve collected, we can afford to do a clean build for 
> the JSC Debug test runs using O3, and still come out way ahead.

This seems like a reasonable plan. You didn't mention what hardware you 
measured with, but it seems certain to be beneficial on any current hardware.

I need to mention that we saw unexplained and very large impact on JSC test 
speed from enabling/disabling TCSM. That may be a good thing to look into while 
optimizing JSC test speed.

- Alexey


> As for non-JSC test runs, I have not actually measured what the time savings 
> are.  Given there is resistance to going with O3 there, we don’t have to 
> share the build artifacts for running the tests.  JSC test runs should be 
> able to just build JSC for each O3 Debug JSC test run and it is still a win 
> over the current status quo i.e. test runs never complete.
> 
> Regarding Geoff’s earlier question about whether I know for sure that 
> switching to O3 will fix the current Debug JSC bot failures to run tests, the 
> answer is I’m not certain.  The failure is a timeout due to the master bot 
> not seeing any output from the tester bot for more than 20 minutes.  I’ve not 
> been able to reproduce this yet.  But with a Debug build test run taking 4+ 
> hours, it can only be a progression to switch the Debug JSC test bots to O3.
> 
> Mark
> 
> 
>> 
 And again, on the run more tests front, it would be helpful to know 
 whether this change was enough to get the stress tests running or not.
>>> My experience running the tests locally supports this fully. I don't get 
>>> timeouts when running O3+Debug locally. When running Debug+O0 locally, I'd 
>>> get timeouts all the time, and the total test run would take ~4-8 hours. We 
>>> can wait for official confirmation from Mark.
>> 
>> Alexey, do the JSC stress tests run now on bots? If not, how fast would they 
>> need to run in order to be eligible to run on bots?
>> 
>> Thanks,
>> Geoff
>> 
>>> 
>>> - Saam
>>> 
 
 Thanks,
 Geoff
 
> On Jun 18, 2020, at 9:30 PM, Saam Barati  > wrote:
> 
> Why are we insisting on doing something on the bots that takes ~10x 
> longer to run than necessary? I’d rather have that time spent running 
> more tests.
> 
> Overall, how we’re doing things now feels like a bad allocation of bot 
> resources. The differences I see between O3 with no-inlining vs O0 is:
> - Some race conditions will behave differently. Race conditions are 
> already non predictable. I don’t think we’re losing anything here.
> - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t 
> in O0, and vice versa. In general, we probably care more about O3 
> compiler bugs than O0, since we don’t ship O0, but ship a lot of O3.
> 
> (And if we’re going to insist on “I want it to run what I build at my 
> desk”: I run debug with O3 at my desk, and I can run debug tests in a 
> reasonable amount of time now.)
> 
> In evaluating what’s the better setu

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

[Alexey Proskuryakov]

> 19 июня 2020 г., в 10:24 AM, Geoffrey Garen  написал(а):
> 
>>> On Jun 19, 2020, at 8:04 AM, Geoffrey Garen >> > wrote:
>>> 
>>> Can you explain more about what "O3 with no-inlining” is? How does 
>>> --force-opt=O3 avoid inlining? Would this fully resolve Simon concern about 
>>> stack traces, or would something still be different about stack traces?
>> There doesn't exist a way to do this now, but it'd be trivial to add a way. 
>> I won't claim it fixes all stack traces differences, but I'd think compiling 
>> using "-fno-inline -fno-optimize-sibling-calls" would get us pretty far in 
>> crashing stack traces being similar enough.
> 
> Sounds good.
> 
> I think we should try to refine the proposal along these lines, to minimize 
> the downsides. I won’t speak for Simon, but for me, being able to ensure a 
> clear backtrace from a bot would be a big improvement.

Enabling some level of optimization is reasonable; whether it should be -O3 
with inlining disabled or -Og is a technical question that probably can't be 
answered without hard data. Also, building locally in the same way as bots do 
could be a show stopper, as people don't like slow builds.

>>> And again, I think this discussion would get a lot more focused if the 
>>> change could apply only to JSC code, and not also to WTF code.
>> I believe Mark's proposal, initially, is just to make JSC do this. So I 
>> don't see the point of compiling WTF differently. JSC can kick off its own 
>> build, and run Debug+O3 tests faster than it can run Debug+O0 tests. Given 
>> people working on JSC want this, and people working on JSC defend these 
>> tests, and that these test results are more stable (see below), we should 
>> make this change for JSC.
>> 
>> I was trying to convince folks defending non-JSC testing, that they too, 
>> should want this. I'm not going to pull teeth here. If folks want their 
>> tests to take ~10x longer to run, they're entitled to make that tradeoff.
> 
> Got it.

To do this only for JSC builds, we'd need separate builders and storage, so it 
becomes a question of allocating more resources, not just switching over to a 
different configuration. While EWS builds for JSC independently, post-commit 
testing shares build artifacts across all testers.

>>> And again, on the run more tests front, it would be helpful to know whether 
>>> this change was enough to get the stress tests running or not.
>> My experience running the tests locally supports this fully. I don't get 
>> timeouts when running O3+Debug locally. When running Debug+O0 locally, I'd 
>> get timeouts all the time, and the total test run would take ~4-8 hours. We 
>> can wait for official confirmation from Mark.
> 
> Alexey, do the JSC stress tests run now on bots? If not, how fast would they 
> need to run in order to be eligible to run on bots?

I don't think that there is a simple answer, as certain variations of stress 
tests get disabled on certain bots, JSC tests have a lot of variations that are 
handpicked. I wouldn't even know how to find the complex answer, but perhaps 
you can get the answer from 

- Alexey



> Thanks,
> Geoff
> 
>> 
>> - Saam
>> 
>>> 
>>> Thanks,
>>> Geoff
>>> 
 On Jun 18, 2020, at 9:30 PM, Saam Barati >>> > wrote:
 
 Why are we insisting on doing something on the bots that takes ~10x longer 
 to run than necessary? I’d rather have that time spent running more tests.
 
 Overall, how we’re doing things now feels like a bad allocation of bot 
 resources. The differences I see between O3 with no-inlining vs O0 is:
 - Some race conditions will behave differently. Race conditions are 
 already non predictable. I don’t think we’re losing anything here.
 - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t 
 in O0, and vice versa. In general, we probably care more about O3 compiler 
 bugs than O0, since we don’t ship O0, but ship a lot of O3.
 
 (And if we’re going to insist on “I want it to run what I build at my 
 desk”: I run debug with O3 at my desk, and I can run debug tests in a 
 reasonable amount of time now.)
 
 In evaluating what’s the better setup, I think it’s helpful to think about 
 this from the other side. Let’s imagine we had Debug+O3 as our current 
 setup. And someone proposed to move it to O0 and make our tests take ~10x 
 longer. I think that’d be a non-starter.
 
 - Saam
 
> On Jun 17, 2020, at 9:48 PM, Simon Fraser  > wrote:
> 
> I also object to losing good stack traces for crashes on Debug bots.
> 
> Also, I don't think Debug bots should build something different from what 
> I build at my desk.
> 
> Simon
> 
>> On Jun 17, 2020, at 1:36 PM, Mark Lam > > wrote:
>> 
>> Hi folks,
>> 
>> We're plan

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

[Alexey Proskuryakov]

> 19 июня 2020 г., в 9:59 AM, Mark Lam  написал(а):
> 
> 
> 
>> On Jun 19, 2020, at 9:53 AM, Alexey Proskuryakov > <mailto:a...@webkit.org>> wrote:
>> 
>> 
>> 
>>> 18 июня 2020 г., в 9:30 PM, Saam Barati >> <mailto:sbar...@apple.com>> написал(а):
>>> 
>>> Why are we insisting on doing something on the bots that takes ~10x longer 
>>> to run than necessary? I’d rather have that time spent running more tests.
>> 
>> Replying to this point specifically, I wanted to point out that WebKit tests 
>> take 2x longer in debug, not 10x longer. JSC tests take 3.6x longer.
> 
> Since I collected real data on this last night on the actual bot that runs 
> the JSC stress tests, I’ll share the data here:
> 
> Build time
> A clean build using buid-jsc for a normal Debug build on bot638 takes about 
> 4.5 minutes.
> A clean build using build-jsc for a --force-opt=O3 Debug build on bot638 
> takes about 6 minutes.
> 
> Test run time
> Running with a regular Debug build, the test completed in about 4 hours 41 
> minutes with 1 timeout.
> Running with a --force-opt=O3 Debug build, the test completed in about 39 
> minutes with 0 timeouts.
> 
> The difference in test run time is 281 minutes vs 29 minutes.  That is a 7.2x 
> ratio, not 3.6x.

https://build.webkit.org/builders/Apple-Catalina-Debug-JSC-Tests/builds/1080 - 
4 hrs, 5 secs
https://build.webkit.org/builders/Apple-Catalina-Release-JSC-Tests/builds/2546 
- 1 hrs, 6 mins, 27 secs

That's 3.6x.

- Alexey



>>> Overall, how we’re doing things now feels like a bad allocation of bot 
>>> resources. The differences I see between O3 with no-inlining vs O0 is:
>> 
>> Last time this was discussed, we talked about -Og, which is specifically 
>> designed for the purpose I believe. Where do we stand on understanding and 
>> adopting that?
> 
> I tried -Og last time after your suggestion, and I remember thinking that the 
> perf was not acceptable back then.  I’ll collect the data again and report 
> back with real number later today.
> 
> Mark
> 
>> 
>> - Alexey
>> 
>>> - Some race conditions will behave differently. Race conditions are already 
>>> non predictable. I don’t think we’re losing anything here.
>>> - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in 
>>> O0, and vice versa. In general, we probably care more about O3 compiler 
>>> bugs than O0, since we don’t ship O0, but ship a lot of O3.
>>> 
>>> (And if we’re going to insist on “I want it to run what I build at my 
>>> desk”: I run debug with O3 at my desk, and I can run debug tests in a 
>>> reasonable amount of time now.)
>>> 
>>> In evaluating what’s the better setup, I think it’s helpful to think about 
>>> this from the other side. Let’s imagine we had Debug+O3 as our current 
>>> setup. And someone proposed to move it to O0 and make our tests take ~10x 
>>> longer. I think that’d be a non-starter.
>>> 
>>> - Saam
>>> 
>>>> On Jun 17, 2020, at 9:48 PM, Simon Fraser >>> <mailto:simon.fra...@apple.com>> wrote:
>>>> 
>>>> I also object to losing good stack traces for crashes on Debug bots.
>>>> 
>>>> Also, I don't think Debug bots should build something different from what 
>>>> I build at my desk.
>>>> 
>>>> Simon
>>>> 
>>>>> On Jun 17, 2020, at 1:36 PM, Mark Lam >>>> <mailto:mark@apple.com>> wrote:
>>>>> 
>>>>> Hi folks,
>>>>> 
>>>>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>>>> <http://build.webkit.org/> Debug build and test bots to building with the 
>>>>> following set first:
>>>>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>>>>> 
>>>>> This means the Debug builds will be built with optimization level forced 
>>>>> to O3.
>>>>> 
>>>>> Why are we doing this?
>>>>> 1. So that the JSC EWS will start catching ASSERT failures.
>>>>> 2. JSC stress test Debug bots have been timing out and not running tests 
>>>>> at all.  Hopefully, this change will fix this issue.
>>>>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>>>>> 
>>>>> The downside: crash stack traces will be like Release build stack traces. 
>>>>>  But I don’t think we should let this deter us.  It’s 

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

[Alexey Proskuryakov]

> 18 июня 2020 г., в 9:30 PM, Saam Barati  написал(а):
> 
> Why are we insisting on doing something on the bots that takes ~10x longer to 
> run than necessary? I’d rather have that time spent running more tests.

Replying to this point specifically, I wanted to point out that WebKit tests 
take 2x longer in debug, not 10x longer. JSC tests take 3.6x longer.

> Overall, how we’re doing things now feels like a bad allocation of bot 
> resources. The differences I see between O3 with no-inlining vs O0 is:

Last time this was discussed, we talked about -Og, which is specifically 
designed for the purpose I believe. Where do we stand on understanding and 
adopting that?

- Alexey

> - Some race conditions will behave differently. Race conditions are already 
> non predictable. I don’t think we’re losing anything here.
> - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in 
> O0, and vice versa. In general, we probably care more about O3 compiler bugs 
> than O0, since we don’t ship O0, but ship a lot of O3.
> 
> (And if we’re going to insist on “I want it to run what I build at my desk”: 
> I run debug with O3 at my desk, and I can run debug tests in a reasonable 
> amount of time now.)
> 
> In evaluating what’s the better setup, I think it’s helpful to think about 
> this from the other side. Let’s imagine we had Debug+O3 as our current setup. 
> And someone proposed to move it to O0 and make our tests take ~10x longer. I 
> think that’d be a non-starter.
> 
> - Saam
> 
>> On Jun 17, 2020, at 9:48 PM, Simon Fraser  wrote:
>> 
>> I also object to losing good stack traces for crashes on Debug bots.
>> 
>> Also, I don't think Debug bots should build something different from what I 
>> build at my desk.
>> 
>> Simon
>> 
>>> On Jun 17, 2020, at 1:36 PM, Mark Lam >> > wrote:
>>> 
>>> Hi folks,
>>> 
>>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>>  Debug build and test bots to building with the 
>>> following set first:
>>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>>> 
>>> This means the Debug builds will be built with optimization level forced to 
>>> O3.
>>> 
>>> Why are we doing this?
>>> 1. So that the JSC EWS will start catching ASSERT failures.
>>> 2. JSC stress test Debug bots have been timing out and not running tests at 
>>> all.  Hopefully, this change will fix this issue.
>>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>>> 
>>> The downside: crash stack traces will be like Release build stack traces.  
>>> But I don’t think we should let this deter us.  It’s not like there’s no 
>>> stack information.  And just as we do with debugging Release build test 
>>> failures, we can always do a Debug build locally to do our debugging.
>>> 
>>> We would like to apply this change to all Debug build and test bots, not 
>>> just the JSC ones.  Does anyone strongly object to this change?
>>> 
>>> Thanks.
>>> 
>>> Cheers,
>>> Mark
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

- Alexey


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

[Alexey Proskuryakov]

I frequently find it critically useful to see stack traces from debug builds, 
because of no inlining. So I don't think that we should do this. A local build 
does not help when the issue is not readily reproducible.

- Alexey


> 17 июня 2020 г., в 1:36 PM, Mark Lam  написал(а):
> 
> Hi folks,
> 
> We're planning to switch the JSC EWS bot and build.webkit.org 
>  Debug build and test bots to building with the 
> following set first:
> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
> 
> This means the Debug builds will be built with optimization level forced to 
> O3.
> 
> Why are we doing this?
> 1. So that the JSC EWS will start catching ASSERT failures.
> 2. JSC stress test Debug bots have been timing out and not running tests at 
> all.  Hopefully, this change will fix this issue.
> 3. Tests will run to completion faster and we’ll catch regressions sooner.
> 
> The downside: crash stack traces will be like Release build stack traces.  
> But I don’t think we should let this deter us.  It’s not like there’s no 
> stack information.  And just as we do with debugging Release build test 
> failures, we can always do a Debug build locally to do our debugging.
> 
> We would like to apply this change to all Debug build and test bots, not just 
> the JSC ones.  Does anyone strongly object to this change?
> 
> Thanks.
> 
> Cheers,
> Mark
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Platform.h vs. makefiles

[Alexey Proskuryakov]

I see substantial appeal in having a separate data file, however I'm not sure 
if it can inform IDE parsing and syntax highlighting for code enabled/disabled 
at compile time. Header files seem like they would get that right more often.

- Alexey


> 10 мая 2020 г., в 10:07 PM, Maciej Stachowiak  написал(а):
> 
> 
> I think the best way to configure WebKit is to use a separate data file, 
> neither a header nor a makefile or similar, that defines the options in a 
> single place with clear syntax. Then everything else is generated from that. 
> Such a system could cover runtime flags as well, which are even more 
> scattered around the project than compile-time flags.
> 
> Moving logic from build files to the header is probably a move in the right 
> direction, though of course it carries risk, particularly for less tested 
> configurations.
> 
> -  Maciej
> 
>> On May 10, 2020, at 5:13 PM, Darin Adler  wrote:
>> 
>> Hi folks.
>> 
>> The Platform.h configuration file family has been useful for WebKit for a 
>> long time. We created it to try to organize configuration options in WebKit 
>> so the would not be spread out through the whole project.
>> 
>> One way to look at these, particularly the ENABLE options, is as a set of 
>> configuration options that let each consumer of the WebKit source code 
>> create a unique flavor of WebKit with the particular features they want 
>> enabled turned on and others turned off. Another is to think of this as a 
>> mechanism for keeping decisions made by the WebKit contributors organized 
>> and easy to understand.
>> 
>> If these truly are WebKit consumer options, then it’s important they be set 
>> as part of the build process. The macros can be defined with a build and 
>> configuration system outside WebKit, and the Platform.h headers should 
>> interpret those values correctly.
>> 
>> On the other hand, if we are just trying to keep our decisions straight, 
>> then it would be best if the logic for what is on and what is off by in the 
>> header files, written with preprocessor macro logic, and not spread across 
>> multiple make files and scripts.
>> 
>> Thus I think the pattern on macOS, for example, of setting these in 
>> .xcconfig files doesn’t make a lot of sense. I think the .xcconfig files 
>> should compute the things that need to be determined about the build 
>> environment, but the configuration decisions should be in files like 
>> PlatformHaveCocoa.h, for example.
>> 
>> I think the guideline should be like this:
>> 
>> All code to compute configuration should be in the Platform.h files, not in 
>> makefiles, with only the following exceptions:
>> 
>> 1) Options like ENABLE(XXX) that some ports wish to offer as options to 
>> people building WebKit can have overridden values in makefiles. But even 
>> these options should have sensible defaults in the Platform.h headers that 
>> express the current status of the port from the point of view of the port’s 
>> maintainers. Ideally we’d find a way to not repeat these default settings 
>> twice.
>> 
>> 2) In some cases, the build machinery needs to contribute to things like 
>> feature detection. So on some platforms, things like HAVE(READLINE) would be 
>> set correctly by the build system.
>> 
>> Options intended to be set by the environment would carefully be wrapped in 
>> #ifndef.
>> 
>> But other options, which simply express relationships between configuration 
>> elements, are designed to be set by Platform.h and not overridden by the 
>> environment, and so they would not be wrapped in #ifndef. Many HAVE options 
>> and most USE options would fall into this category.
>> 
>> What do you all think?
>> 
>> — Darin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Introducing a minimum ICU version for WebKit

[Alexey Proskuryakov]

The license is not BSD or LGPL, so that's one aspect to consider.

Why exactly are distros unwilling to update ICU?

- Alexey


> 9 апр. 2020 г., в 10:32 AM, Michael Catanzaro  
> написал(а):
> 
> 
> Any objections to uploading a bundled ICU 60 under Source/ThirdParty?
> 
> Seems easier than forcing downstreams to work out bundling themselves. Most 
> major distros will just stop providing WebKit security updates if we don't 
> bundle it for them. E.g. this is sure to kill Ubuntu's current long streak of 
> providing our updates to Ubuntu 16.04.
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Checking out WebKit source code when using Xcode 11.4

[Alexey Proskuryakov]

Hello everyone,

Xcode 11.4 was released today, and it does not include svn or git-svn any more. 
We have posted a standalone installer at  to 
keep getting tools needed for WebKit development easy.

- Alexey
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

[Alexey Proskuryakov]

> 6 марта 2020 г., в 18:29, Ryosuke Niwa  написал(а):
> 
> On Fri, Mar 6, 2020 at 6:15 PM Kirsling, Ross  wrote:
>> 
>> Late on Friday seems like a good time for a terminological debate (), so I’d 
>> like to propose we revisit one of the strangest items of WebKit-specific 
>> terminology: the phrase ‘roll out’.
>> 
>> In our industry, the typical meaning of the phrase ‘roll out’ is, of course, 
>> ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of ‘roll 
>> out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ to 
>> mean the exact opposite, ‘revert’ or ‘roll back’.
> 
> I think the ship has sailed on this one. People who have been working
> on the WebKit project for long enough are so used to the phrase
> "rollout a patch" that it's gonna be tricky to change the terminology.
> Having said that, I'd much prefer the term "revert" over "rollout" or
> "rollback".

I've been using "roll back" lately, but "revert" seems perfectly fine.

- Alexey

> It's also the term git uses.
>> This term is confusing enough for native English speakers outside our 
>> community, let alone non-natives (since phrasal verbs are notoriously tricky 
>> as it is).
> 
> As a non-native speaker myself, I never find this term confusing
> because I have no mental model of what "rollout" or "rollback" means.
> However, I find those two terms infinitely more confusing than the
> very direct "revert".
> 
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Clearing old reviews from the queue

[Alexey Proskuryakov]

> 16 февр. 2020 г., в 7:52, Dean Jackson  написал(а):
> 
> Does anyone oppose clearing all review requests that are older than 6 months? 
> (or 1 year?)

Looking at ancient patches in the review queue, quite a few look like they 
should still work (e.g. adding new tests). So said that we are not keeping up 
with reviews, even for simple patches.

> I tried to use the bugzilla API to do this, but I couldn't work out how to 
> detect the attachment state properly. I looked at the source code for the 
> queue page and it uses custom SQL :)

What were you trying to do, and how far did you get?

- Alexey

> (It's easy to do with the GitHub API)
> 
> Dean
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Handling flaky layout-test failures in EWS

[Alexey Proskuryakov]

> 5 дек. 2019 г., в 7:58 AM, Aakash Jain  написал(а):
> 
> > What is the current behavior when a patch introduces substantial flakiness?
> 
> For the patch which introduces substantial flakiness (and no consistent 
> failure in EWS), prior to r253049 (which I landed two days back), the patch 
> would be infinitely retried (unless atleast one of the flaky test failed 
> consistently, or the patch is obsolete).
> 
> After r253049, the patch would be marked as passing. EWS is simply not 
> detecting flakiness introduced by a patch (since it doesn't know if the 
> flakiness is introduced by the patch or was pre-existing). However, if any of 
> those 10 tests failed consistently in two runs, the patch would be marked as 
> failing.
> 
> We can work towards improving EWS to better detect flakiness by using data 
> from new flakiness dashboard (which now has the API as well).
> 
> > This looks like decent evidence to make the EWS bubble red.
> We can do that. Have we seen any patch in the past which would fail 5+ tests 
> in first run, and fail completely different 5+ tests in second run? Also, 
> what should be the threshold, should it be 10 (5+5) different test failures 
> (or lower) in two runs?

This would have been difficult to see recently, because EWS just retried when 
hitting this. But I've certainly seen patches that increased flakiness like 
this, so it's a practical case.

Starting with 10 more test failures on two retries (combined) than in a clean 
run seems reasonable.

- Alexey


> Thanks
> Aakash
> 
>> On Dec 3, 2019, at 12:28 PM, Alexey Proskuryakov > <mailto:a...@webkit.org>> wrote:
>> 
>> 
>> Yes, I think that this makes more sense than retrying.
>> 
>> What is the current behavior when a patch introduces substantial flakiness? 
>> E.g. this scenario:
>> 
>> - First test run produces 5 failures.
>> - Second test run produces 5 different failures.
>> - Clean re-run produces no failures.
>> 
>> This looks like decent evidence to make the EWS bubble red. I don't know 
>> what exactly the threshold should be, but that should certainly be below 30.
>> 
>> - Alexey
>> 
>> 
>>> 3 дек. 2019 г., в 8:40 AM, Aakash Jain >> <mailto:aakash_j...@apple.com>> написал(а):
>>> 
>>> Hi Everyone,
>>> 
>>> We have various layout-tests which are flaky (which sometimes pass and 
>>> sometimes fail/crash/timeout). EWS needs to work despite these flaky tests, 
>>> and need to be able to tell whether the patch being tested introduced any 
>>> test failure or not.
>>> 
>>> In EWS, we have logic (same logic in both old and new EWS) on how to deal 
>>> with flaky tests. The logic is roughly following:
>>> 
>>> - We apply the patch and build.
>>> 
>>> - Run layout-tests. During the test-run, we retry the failed tests. If 
>>> those tests pass in retry, the run is considered to have no failing test 
>>> (this retry part is same for EWS / build.webkit.org 
>>> <http://build.webkit.org/> / manual-run and part of run-webkit-test script 
>>> itself).
>>> 
>>> - If a test-run has some failures, EWS retry the test-run one more time (to 
>>> check if those test failures were flaky). 
>>> 
>>> - Then we do one more test-run on clean-tree (without the patch), and 
>>> compare the results of first run, second run, and clean tree run.
>>> 
>>> - After that we analyze the results from all three test-runs (which we call 
>>> first_run, second_run and clean_tree_run). 
>>> 
>>> 
>>> If there are different test failures in first and second runs (i.e.: flaky 
>>> test failures), and the patch being tested did not introduce any new test 
>>> failure, we retry the entire build (probably hoping that next time we will 
>>> not see the flakiness). This retry can result in almost infinite loop, if 
>>> someone commits a very flaky test (which is not rare), and would cause EWS 
>>> to be almost stuck until the flakiness is fixed.
>>> 
>>> From 
>>> https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/tool/bot/patchanalysistask.py#L352
>>>  
>>> <https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/tool/bot/patchanalysistask.py#L352>
>>>   ('Defer' means retrying the build).
>>> '''
>>> 350# At this point we know that at least one test flaked, but no 
>>> consistent failures
>>> 351# were introduced. This is a bit of a grey-

Re: [webkit-dev] Handling flaky layout-test failures in EWS

[Alexey Proskuryakov]

Yes, I think that this makes more sense than retrying.

What is the current behavior when a patch introduces substantial flakiness? 
E.g. this scenario:

- First test run produces 5 failures.
- Second test run produces 5 different failures.
- Clean re-run produces no failures.

This looks like decent evidence to make the EWS bubble red. I don't know what 
exactly the threshold should be, but that should certainly be below 30.

- Alexey


> 3 дек. 2019 г., в 8:40 AM, Aakash Jain  написал(а):
> 
> Hi Everyone,
> 
> We have various layout-tests which are flaky (which sometimes pass and 
> sometimes fail/crash/timeout). EWS needs to work despite these flaky tests, 
> and need to be able to tell whether the patch being tested introduced any 
> test failure or not.
> 
> In EWS, we have logic (same logic in both old and new EWS) on how to deal 
> with flaky tests. The logic is roughly following:
> 
> - We apply the patch and build.
> 
> - Run layout-tests. During the test-run, we retry the failed tests. If those 
> tests pass in retry, the run is considered to have no failing test (this 
> retry part is same for EWS / build.webkit.org / manual-run and part of 
> run-webkit-test script itself).
> 
> - If a test-run has some failures, EWS retry the test-run one more time (to 
> check if those test failures were flaky). 
> 
> - Then we do one more test-run on clean-tree (without the patch), and compare 
> the results of first run, second run, and clean tree run.
> 
> - After that we analyze the results from all three test-runs (which we call 
> first_run, second_run and clean_tree_run). 
> 
> 
> If there are different test failures in first and second runs (i.e.: flaky 
> test failures), and the patch being tested did not introduce any new test 
> failure, we retry the entire build (probably hoping that next time we will 
> not see the flakiness). This retry can result in almost infinite loop, if 
> someone commits a very flaky test (which is not rare), and would cause EWS to 
> be almost stuck until the flakiness is fixed.
> 
> From 
> https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/tool/bot/patchanalysistask.py#L352
>   ('Defer' means retrying the build).
> '''
> 350# At this point we know that at least one test flaked, but no 
> consistent failures
> 351# were introduced. This is a bit of a grey-zone.
> 352return False  # Defer patch
> '''
> 
> 
> Retrying the entire build, just because of few flaky tests seems excessive 
> and inefficient. This doesn't help identify flaky tests, and only delays the 
> EWS result. Instead, we should mark the build as SUCCESS (since the patch did 
> not introduce any new consistent test failure).
> 
> In other EWS test-suites like API tests and JSC tests, we do not retry the 
> entire build on flaky test failures, we ignore the flaky tests, and only 
> focus on tests which failed consistently. We should do the similar thing for 
> layout-tests as well.
> 
> I am going to make that change for layout tests in 
> https://bugs.webkit.org/show_bug.cgi?id=204769. Please let me know if anyone 
> has a different opinion.
> 
> Thanks
> Aakash


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

[Alexey Proskuryakov]

> 10 нояб. 2019 г., в 1:16 AM, Noam Rosenthal  написал(а):
> 
> Hola
> 
> I would like to open a discussion that has started a few years back and has 
> never reached a consensus: https://bugs.webkit.org/show_bug.cgi?id=145380 
> 
> 
> In a nutshell: content-dpr is a response-only header for images, that allows 
> servers at transient layers (CDNs/proxies) to optimize images by changing 
> their resolution, allowing the user agents to compensate for the change in 
> intrinsic size caused by the resolution change - thus making the resolution 
> change transparent to users. It's the header that makes the 
> resolution-encoding transparent.
> 
> The feature is already up and running in chrome since version 67, and is used 
> by some CDNs.
> 
> Since there was lack of consensus in the bug discussion, I wanted to make the 
> case for it here, and see if opinions about the subject can be voiced before 
> we reach a decision/consensus. I tried to find a good balance between being 
> detailed and being concise. 
> 
> —
> 
> Players in CDN, proxy and other transient parts of the internet world have 
> innovated a lot in the past few years. There are lots of interesting 
> companies and competition there. One of the areas of this innovation is in 
> optimizing images in a transparent way at transient layers (proxy/CDN). This 
> makes a lot of sense considering how much of internet traffic is taken by 
> image download.
> 
> What the research at the CDN companies found, was that modifying resolution 
> at the transient layer can have a tremendous effect on 
> performance/user-experience balance, for example by serving lower-resolution 
> versions of the images when network traffic is costly/slow (the exact formula 
> for that is part of where the CDN can innovate). More details on that 
> innovation in the links below.
> 
> The thing is, that modifying image resolution at the CDN/proxy is not 
> inherently transparent, due to one reason - layout is affected by the image’s 
> intrinsic size, and changing the image’s resolution inadvertently changes the 
> image’s intrinsic size. To make this transparent, the user agent has to be 
> involved, to compensate for this optimization when reading the image’s 
> intrinsic size.
> 
> The main case against this feature was that image resolution is a feature 
> that should be handled at the markup layer and not at the transport layer 
> (https://bugs.webkit.org/show_bug.cgi?id=145380#c7 
> ).
> I would argue that http-headers are not a transport layer (TCP/UDP etc.), but 
> rather part of an application-layer protocol that is designed, in part, to 
> pass information to the transient layers such as CDNs, and that resolution 
> compression is a (new, image-specific) equivalent of transfer-encoding. 
> 
> Also, as a response to the view that this should be part of markup, I would 
> argue that those transparent decisions by the servers should not concern web 
> authors at all. It’s an optimization decision to be handled by the servers, 
> with the user agent doing nothing about it but allow that decision to be 
> transparent in terms of layout (the same way gzip and cache-control are 
> transparent).

I don't see this as a precedent, because cache control and compression are 
invisible to users. Whereas image quality most certainly is. Changing it behind 
both web developer and user back would cause lots of undesirable behaviors - 
say, I e-mail an image from a webpage to someone else, who doesn't have a small 
display, or just zoom in to see the details.

This basically results in the website being untestable by the author (or by UA 
implementers who will be getting bug reports about site behavior differences).

Also, maybe I'm just pessimistic here, but it seems almost inevitable that 
disagreements between markup, Content-DPR and dpi information embedded in 
images will be handled by UAs differently, even if the spec ends up being very 
detailed on this point.

- Alexey


> What is offered here is a win-win in terms of delivering images, and would 
> allow webkit-browser users to enjoy some of the innovations in the image 
> delivery world without modifying their HTML content and without concern of 
> breaking their layouts. Less battery and data used for downloading big images 
> at certain situations, for example.
> 
> I hope this provides enough background without being too tedious. I would be 
> happy to shed more light on whatever is missing in this longish essay :)
> 
> Additional info:
> https://github.com/eeeps/content-dpr-explainer 
> 
> https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67
>  
> 
> https://www.chromestatus.com/metrics/feature/timeline/popularity/906 
> 

Re: [webkit-dev] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

[Alexey Proskuryakov]

> 4 нояб. 2019 г., в 1:37 PM, Ryosuke Niwa  написал(а):
> 
> 
> On Mon, Nov 4, 2019 at 9:40 AM Alexey Proskuryakov  <mailto:a...@webkit.org>> wrote:
> 
> Can you elaborate on that, how exactly is e-mailing on first failure useful 
> to reviewers?
> 
> Getting rid of Bugzilla comments was one of the goals of EWS rewrite, based 
> on engineering feedback about noise in bugs and in e-mail, and I 
> wholeheartedly agree with this feedback. So I think that comments are 
> generally undesirable.
> 
> Since I don't understand what your precise scenario is, I may be make straw 
> man arguments below, but here are some things that I think make the proposed 
> behavior unhelpful (add a comment on first failure, or when all EWSes pass).
> 
> 1. EWS comments in Bugzilla are so annoying that some people take the radical 
> step of manually hiding them. EWS history is archived anyway, there is no 
> need to look into comments for it.
> 
> 2. There are often many people CC'ed on the bug to whom EWS data is 
> irrelevant or even mysterious (e.g. reporters, web developers or 
> non-reviewers). The noise is a slight annoyance, discouraging further 
> participation in the project.
> 
> 3. I believe that for most reviewers, the mode of operation is one of the 
> two: (1) do it when pinged directly, or (2) go over the review queue when one 
> has the time. Getting EWS comments helps neither.
> 
> 4. Commenting when all EWSes pass is not very practical - it's too often that 
> we have some stragglers that take days (or forever). I don't think that we 
> can make it reliable even if we start actively policing EWS responsiveness.
> 
> 5. The reviewer likely wants to know the state of multiple EWSes if they are 
> going to wait for EWS at all. What exactly are they going to do after getting 
> an e-mail that one EWS failed?
> 
> I often use a EWS failure as a signal to wait reviewing a patch. Otherwise, a 
> bug mail will stay in my inbox as one of items to get to.
> 
> I can see the usefulness in the somewhat unusual case of a super urgent 
> patch. We may want multiple people to watch it, so that members of CC list 
> would go and ask the patch author to update it with more urgency than e-mail 
> allows for. I think that opt-in is a better mechanism for that, so that 
> people who opted in would receive information about each EWS data point.
> 
> I think there is a value in knowing that a patch isn't ready instead of 
> having to open the bug to realize that.

So just to clarify, 

- a major part of how you get to review bugs is by being CC'ed, and you review 
them when you have the time to read bugmail;
- and you don't open the bug in Bugzilla if there is already an EWS failure by 
the time you read the e-mail where review is requested?

That's clearly a valid benefit. In my mind, it probably doesn't outweigh the 
downsides. On the other hand, yours is a voice of someone who reviews way more 
patches than Maciej and me combined these days, so maybe more e-mail is an 
overall benefit to many of the reviewers.

- Alexey



> - R. Niwa
>> 3 нояб. 2019 г., в 6:58 PM, Maciej Stachowiak > <mailto:m...@apple.com>> написал(а):
>> 
>> 
>> I think they are useful to actual and potential reviewers. Direct email to 
>> the patch author is not something anyone can Cc themselves on, and is not 
>> archived, so seems like a strictly worse form of communication.
>> 
>>> On Nov 2, 2019, at 9:34 AM, Alexey Proskuryakov >> <mailto:a...@apple.com>> wrote:
>>> 
>>> 
>>> My preference is still e-mailing the patch author directly (possibly, also 
>>> having an option to opt in for anyone). Bugzilla comments will always be 
>>> irrelevant for most people CC'ed on the bug, and they are almost always 
>>> undesirable to keep within the discussion flow.
>>> 
>>> - Alexey
>>> 
>>>> 1 нояб. 2019 г., в 18:28, Aakash Jain >>> <mailto:aakash_j...@apple.com>> написал(а):
>>>> 
>>>> Sounds good. I prefer the single comment when the first failure occur. 
>>>> That way notification would be sent as soon as the first failure happens.
>>>> 
>>>> I'll implement that (assuming it's acceptable to everyone).
>>>> 
>>>> Thanks
>>>> Aakash
>>>> 
>>>>> On Nov 1, 2019, at 8:35 PM, Maciej Stachowiak >>>> <mailto:m...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>> How about only a single comment when the first failure occurs? (Or else 
>>>>> when all bots pass, if there i

Re: [webkit-dev] iOS EWS behind by 3 days??

[Alexey Proskuryakov]

> 4 нояб. 2019 г., в 11:30 PM, Ryosuke Niwa  написал(а):
> 
> Hi all,
> 
> Does anyone know what's happening with iOS EWS?

Not yet, but it's part of a cluster of problems related to interactions between 
simulator and specific macOS host versions.

https://bugs.webkit.org/show_bug.cgi?id=203792 tracks this particular issue.

- Alexey


> They're ~3 days behind now:
> https://ews-build.webkit.org/#/builders/24 
> 
> 
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

[Alexey Proskuryakov]

Can you elaborate on that, how exactly is e-mailing on first failure useful to 
reviewers?

Getting rid of Bugzilla comments was one of the goals of EWS rewrite, based on 
engineering feedback about noise in bugs and in e-mail, and I wholeheartedly 
agree with this feedback. So I think that comments are generally undesirable.

Since I don't understand what your precise scenario is, I may be make straw man 
arguments below, but here are some things that I think make the proposed 
behavior unhelpful (add a comment on first failure, or when all EWSes pass).

1. EWS comments in Bugzilla are so annoying that some people take the radical 
step of manually hiding them. EWS history is archived anyway, there is no need 
to look into comments for it.

2. There are often many people CC'ed on the bug to whom EWS data is irrelevant 
or even mysterious (e.g. reporters, web developers or non-reviewers). The noise 
is a slight annoyance, discouraging further participation in the project.

3. I believe that for most reviewers, the mode of operation is one of the two: 
(1) do it when pinged directly, or (2) go over the review queue when one has 
the time. Getting EWS comments helps neither.

4. Commenting when all EWSes pass is not very practical - it's too often that 
we have some stragglers that take days (or forever). I don't think that we can 
make it reliable even if we start actively policing EWS responsiveness.

5. The reviewer likely wants to know the state of multiple EWSes if they are 
going to wait for EWS at all. What exactly are they going to do after getting 
an e-mail that one EWS failed?

6. More bugmail delays response, especially for active project members who are 
CC'ed on a lot of bugs. I personally started reading bugmail more frequently 
now, knowing that there is more signal and less noise.

I can see the usefulness in the somewhat unusual case of a super urgent patch. 
We may want multiple people to watch it, so that members of CC list would go 
and ask the patch author to update it with more urgency than e-mail allows for. 
I think that opt-in is a better mechanism for that, so that people who opted in 
would receive information about each EWS data point.

- Alexey


> 3 нояб. 2019 г., в 6:58 PM, Maciej Stachowiak  написал(а):
> 
> 
> I think they are useful to actual and potential reviewers. Direct email to 
> the patch author is not something anyone can Cc themselves on, and is not 
> archived, so seems like a strictly worse form of communication.
> 
>> On Nov 2, 2019, at 9:34 AM, Alexey Proskuryakov  wrote:
>> 
>> 
>> My preference is still e-mailing the patch author directly (possibly, also 
>> having an option to opt in for anyone). Bugzilla comments will always be 
>> irrelevant for most people CC'ed on the bug, and they are almost always 
>> undesirable to keep within the discussion flow.
>> 
>> - Alexey
>> 
>>> 1 нояб. 2019 г., в 18:28, Aakash Jain  написал(а):
>>> 
>>> Sounds good. I prefer the single comment when the first failure occur. That 
>>> way notification would be sent as soon as the first failure happens.
>>> 
>>> I'll implement that (assuming it's acceptable to everyone).
>>> 
>>> Thanks
>>> Aakash
>>> 
>>>> On Nov 1, 2019, at 8:35 PM, Maciej Stachowiak  wrote:
>>>> 
>>>> 
>>>> How about only a single comment when the first failure occurs? (Or else 
>>>> when all bots pass, if there is never a failure.)
>>>> 
>>>> This should help the author, the reviewer, and anyone else cc’d, without 
>>>> being too spammy.
>>>> 
>>>>> On Nov 1, 2019, at 5:20 PM, Aakash Jain  wrote:
>>>>> 
>>>>> Hi Ryosuke,
>>>>> 
>>>>> Many people didn't like the noise by the EWS comments, and we removed the 
>>>>> comments as per previous discussion in: 
>>>>> https://lists.webkit.org/pipermail/webkit-dev/2019-June/030683.html.
>>>>> 
>>>>> I agree with your point that having some kind of notification might be 
>>>>> useful.
>>>>> 
>>>>> I proposed some ideas in 
>>>>> https://lists.webkit.org/pipermail/webkit-dev/2019-September/030798.html, 
>>>>> but didn't get much feedback. If we can all agree on a solution, I can 
>>>>> look into implementing it.
>>>>> 
>>>>> Thanks
>>>>> Aakash
>>>>> 
>>>>>> On Oct 30, 2019, at 1:03 AM, Ryosuke Niwa  wrote:
>>>>>> 
>>>>>> These enhancements are great. There is one feature of the old EWS that I 
>>>&g

Re: [webkit-dev] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

[Alexey Proskuryakov]

My preference is still e-mailing the patch author directly (possibly, also 
having an option to opt in for anyone). Bugzilla comments will always be 
irrelevant for most people CC'ed on the bug, and they are almost always 
undesirable to keep within the discussion flow.

- Alexey

> 1 нояб. 2019 г., в 18:28, Aakash Jain  написал(а):
> 
> Sounds good. I prefer the single comment when the first failure occur. That 
> way notification would be sent as soon as the first failure happens.
> 
> I'll implement that (assuming it's acceptable to everyone).
> 
> Thanks
> Aakash
> 
>> On Nov 1, 2019, at 8:35 PM, Maciej Stachowiak  wrote:
>> 
>> 
>> How about only a single comment when the first failure occurs? (Or else when 
>> all bots pass, if there is never a failure.)
>> 
>> This should help the author, the reviewer, and anyone else cc’d, without 
>> being too spammy.
>> 
>>> On Nov 1, 2019, at 5:20 PM, Aakash Jain  wrote:
>>> 
>>> Hi Ryosuke,
>>> 
>>> Many people didn't like the noise by the EWS comments, and we removed the 
>>> comments as per previous discussion in: 
>>> https://lists.webkit.org/pipermail/webkit-dev/2019-June/030683.html.
>>> 
>>> I agree with your point that having some kind of notification might be 
>>> useful.
>>> 
>>> I proposed some ideas in 
>>> https://lists.webkit.org/pipermail/webkit-dev/2019-September/030798.html, 
>>> but didn't get much feedback. If we can all agree on a solution, I can look 
>>> into implementing it.
>>> 
>>> Thanks
>>> Aakash
>>> 
 On Oct 30, 2019, at 1:03 AM, Ryosuke Niwa  wrote:
 
 These enhancements are great. There is one feature of the old EWS that I 
 really miss, which is that I used to get emails when some EWS failed. With 
 new EWS, I have to keep checking back the bugzilla to see if any of them 
 have failed periodically.
 
 Can we add a feature to opt into such an email notification? Maybe a flag 
 on a patch or JSON configuration file somewhere.
 
 - R. Niwa
 
 On Tue, Oct 29, 2019 at 4:05 PM Aakash Jain  wrote:
 Hi Everyone,
 
 I am happy to announce another EWS feature.
 
 From now on, in case of build failure, EWS will parse the errors and 
 display them in a separate 'errors' log. You wouldn't have to search 
 through thousands of lines of logs to find the error message.
 
 For example, in https://ews-build.webkit.org/#/builders/16/builds/6054, in 
 step #7 WebKit failed to compile. Complete logs (stdio) are 38,000+ lines, 
 and the error is not at the end of the logs. Normally, it requires some 
 searching through the logs to find the relevant errors. But now, there is 
 another 'errors' log, which contains just the relevant 11 lines 
 (containing error and few related lines to provide additional context).
 
 Hopefully this would save some time and efforts previously spent on 
 searching through the large logs.
 
 Note that this information is not displayed in status-bubble tool-tip, 
 since this might be lot of text to display in the tooltip. My further plan 
 is to make this information more readily available, by adding it to a 
 custom designed page which will open on clicking the status bubble 
 https://webkit.org/b/197522
 
 Please let me know if you notice any issues or have any feedback.
 
 Thanks
 Aakash
 
 Reference: https://webkit.org/b/203418
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 -- 
 - R. Niwa
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] 2019 WebKit Contributors Meeting - Hurry! Registration is Closing!

[Alexey Proskuryakov]

Seems like an issue to look into. However this should not prevent you from 
registering, because you do have a Trac account (it's the same thing as your 
svn account).

- Alexey


> 25 окт. 2019 г., в 8:07 AM, Geoffrey Garen  написал(а):
> 
> The Login page looks like this:
> 
> 
> 
> If you click the  link, it takes you to 
> https://webkit.org/auth/wregister . 
> 
> I’m not sure what “not used for registration this year means”; but what I 
> mean is that this link is present on the page, and clicking it loads an error 
> page.
> 
> Thanks,
> Geoff
> 
>> On Oct 24, 2019, at 11:11 PM, Ling Ho > > wrote:
>> 
>> Hi Geoff,
>> 
>> Please go to https://webkit.org/auth/wlogout/ 
>>  and make sure you are not logged in. Then 
>> go to https://www.webkit.org/meeting  and 
>> make sure the pages says "2019 WebKit Contributors Meeting". After that, try 
>> logging in and register again. The "https://webkit.org/auth/wregister 
>> " is not used for registration this year.
>> 
>> ...
>> ling
>> 
>> On 10/24/19 9:12 PM, Geoffrey Garen wrote:
>>> https://webkit.org/auth/wregister 
>>> 
>>> Internal Server Error
>>> 
>>> The server encountered an internal error or misconfiguration and was unable 
>>> to complete your request.
>>> 
>>> Please contact the server administrator at ad...@webkit.org 
>>>  to inform them of the time this error occurred, 
>>> and the actions you performed just before this error.
>>> 
>>> More information about this error may be available in the server error log.
>>> 
>>> 
 On Oct 23, 2019, at 4:06 PM, Jonathan Davis >>> > wrote:
 
 Hello WebKit Contributors,
 
 This is a short reminder that your chance to register to attend the WebKit 
 Contributors Meeting is closing after Friday, October 25th!
 
 Please be sure you’ve registered for the meeting at 
 https://webkit.org/meeting/ 
 
 The schedule of topics is filling in, but there are still a couple of 
 larger time slots available. If you have a topic you’d like to present for 
 discussion, please send me an email to secure a spot on the schedule.
 
 Note that the longer prepared talks are anywhere between 30-40 minutes 
 leaving time for questions and discussions before the next session. If you 
 have a short topic to present, email me about giving a 5-10 minute 
 lightning talk.
 
 See you next Friday!
 
 Jon Davis
 
> On Sep 18, 2019, at 1:47 PM, Jonathan Davis  > wrote:
> 
> Hello WebKit Contributors,
> 
> You are invited to attend the annual WebKit Contributors Meeting to be 
> held at the Hilton Santa Clara hotel on Friday, November 1st, 2019 from 8 
> AM to 6 PM Pacific.
> 
> Breakfast and sign-in will begin at 8 AM. Presentations will run between 
> 9 AM to 6 PM. Lunch will be provided with all day coffee, tea and a 
> mid-afternoon snack break. A reception is planned at the venue after the 
> meeting with dinner and drinks from 6 PM to 9 PM.
> 
> To attend you must be an active WebKit contributor. The meeting will be 
> free of charge, and registration is open. Register at 
> https://webkit.org/meeting/  
> 
> The event format will include a mix of prepared talks around 40 minutes 
> long with 10-15 minutes of questions, and spontaneous lightning talks 
> about 5-10 minutes long. If you have a topic idea that you want to 
> present, please email me directly.
> 
> We look forward to seeing you there!
> 
> Thank you,
> Jon Davis
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org 
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 
>>> 
>>> 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> 
>> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving to Python 3

[Alexey Proskuryakov]

> 15 июля 2019 г., в 23:04, Fujii Hironori  
> написал(а):
> 
> 
> On Sun, Jul 14, 2019 at 7:44 AM Ryosuke Niwa  > wrote:
> 
> I don’t think anyone is arguing that we’d eventually need to move to Python3. 
> I’m arguing that it’s not okay to require random WebKit contributor to know 
> some obscure python insanity to install Python 3, or have a script that 
> installs Python 3 and breaks all other python scripts in the system.
> 
> 
>  Just out of curiosity. As far as I know, installing Python 3 breaks nothing. 
> What and why are they got broken?

As always, it will be up to the people doing the work to decide how it's done. 
The feedback is clear:

- They shouldn't make it excessively difficult to do WebKit engineering on 
older versions of macOS.

"Excessively" is not clearly defined, but it seems obvious that there is a 
tradeoff between tools work difficulty, and difficulty for engineers who go 
back to older macOS versions (and implicitly, difficulty for people who set up 
bots, QA engineers, and others involved).

I don't think that anyone ever suggested that it will be up to each engineer to 
figure out the best way to install Python 3.

- virtualenv works great for some projects.

Definitely worth looking at it as one of the primary paths forward. It's not 
just Python itself, but we don't want to pollute the system with modules 
either. Although the latter already has a pretty nice solution in WebKit with 
autoinstall.

- virtualenv shouldn't be required when building WebKit, and dynamic 
dependencies in general are not OK in this scenario.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Changing the svn commit hook to allow tabs for tests.

[Alexey Proskuryakov]

> 10 мая 2019 г., в 13:50, Darin Adler  написал(а):
> 
>> On May 10, 2019, at 1:13 PM, Keith Miller  wrote:
>> 
>> I’m not sure I know what you mean by allow a whole-directory exception. Do 
>> you mean a top level directory? Or some kind of parameter we pass to the 
>> hook to ignore some directory for that run?
> 
> I meant that we could add something the pre-commit hook could see in 
> Subversion that would create an exception for a whole directory, rather than 
> something inside the hook itself. Perhaps a specially named file, or a 
> Subversion attribute on a specially named file, or something more clever. If 
> Subversion had attributes on directories, it could be that.

Subversion supports properties on directories, we use those for svn:ignore as 
an example. It is correct that the pre-commit hook doesn't currently check 
parent directory properties.

An alternative is to just set it on all files in the directory.

>> you can’t commit with git-svn as it doesn’t support svn properties (or at 
>> least I wasn’t able to figure it out)
> 
> Ah, that’s a big blocker if lots of people are using git-svn — I certainly 
> use it.

Looks like it may now work with recent versions of git (as in since 2015), 
https://stackoverflow.com/questions/1271449/how-to-set-subversion-properties-with-git-svn
 :

git-svn: support for git-svn propset

This change allows git-svn to support setting subversion properties.

It is useful for manually setting properties when committing to a subversion 
repo that requiresproperties to be set without requiring moving your changeset 
to separate subversion checkout in order to set props.

There is a nit to point out: the code does not support adding props unless 
there are also content changes to the files as well.
This is demonstrated in the testcase.

- Alexey

> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Spam and indexing

[Alexey Proskuryakov]

I posted a tool that I used for this today to 
https://bugs.webkit.org/show_bug.cgi?id=197537. Probably a lot to improve, but 
it works.

- Alexey


> 2 мая 2019 г., в 14:32, Darin Adler  написал(а):
> 
> Should we post instructions somewhere for people dealing with spam? I believe 
> the instructions are:
> 
> 1) Look up the email address of the account that posted the spam and disable 
> it first, so spammers don’t get email about other steps. Do this by clicking 
> on Administration, Users, finding the user and putting the word “Spam” into 
> the disable text.
> 
> 2) Move any spam bugs into the Spam component.
> 
> 3) Mark any spam comments as Private and also add the tag “spam”.
> 
> But maybe there’s more to it than that. For example, can someone without 
> administration privileges do the right thing? Should we make a small tool to 
> make this easier to do correctly?
> 
> I like the idea of having instructions so this isn’t oral tradition.
> 
> — Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Spam and indexing

[Alexey Proskuryakov]

One change that I'm going to make is to mark spam comments as private instead 
of simply tagging. That way, bugs will look cleaner, and there will be no doubt 
about whether search engines index hidden comments or not.

I'll also mark old spam comments as private. I think that this will generate 
e-mail notifications, so apologies for the upcoming e-mail storm. These should 
be possible to delete all at once in most e-mail clients.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Spam and indexing

[Alexey Proskuryakov]

> 28 марта 2019 г., в 14:10, Konstantin Tokarev  написал(а):
> 
> 
> 
> 28.03.2019, 23:58, "Alexey Proskuryakov" :
>> Hello,
>> 
>> The robots.txt file that we have on bugs.webkit.org currently allows search 
>> engines access to individual bug pages, but not to any bug lists. As a 
>> result, search engines and the Internet Archive only index bugs that were 
>> filed before robots.txt changes a few years ago, and bugs that are directly 
>> linked from webpages elsewhere. These bugs are where most spam content 
>> naturally ends up on.
>> 
>> This is quite wrong, as indexing just a subset of bugs is not beneficial to 
>> anyone other than spammers. So we can go in either direction:
>> 
>> 1. Allow indexers to enumerate bugs, thus indexing all of them.
>> 
>> Seems reasonable that people should be able to find bugs using search 
>> engines.
> 
> Yes, and it may give better result even than searching bugzilla directly
> 
>> On the other hand, we'll need to do something to ensure that indexers don't 
>> destroy Bugzilla performance,
> 
> This can be solved by caching

Is this something that other Bugzilla instances do? I'm actually not sure how 
caching can be meaningfully applied to Bugzilla. One wants to always see the 
latest updates, and our automation in particular won't be OK with stale data.

- Alexey

>> and of course spammers will love having more flexibility.
> 
> rel="nofollow" on all links in comments should be enough to make spamming 
> useless
> 
>> 
>> 2. Block indexing completely.
>> 
>> Seems like no one was bothered by lack of indexing on new bugs so far.
> 
> That's survival bias - if nobody can find relevant bugs, nobody will ever 
> complain
> 
>> 
>> Thoughts?
>> 
>> For reference, here is the current robots.txt content:
>> 
>> $ curl https://bugs.webkit.org/robots.txt
>> User-agent: *
>> Allow: /index.cgi
>> Allow: /show_bug.cgi
>> Disallow: /
>> Crawl-delay: 20
>> 
>> - Alexey
>> - Alexey
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin
> 



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Spam and indexing

[Alexey Proskuryakov]

Hello,

The robots.txt file that we have on bugs.webkit.org currently allows search 
engines access to individual bug pages, but not to any bug lists. As a result, 
search engines and the Internet Archive only index bugs that were filed before 
robots.txt changes a few years ago, and bugs that are directly linked from 
webpages elsewhere. These bugs are where most spam content naturally ends up on.

This is quite wrong, as indexing just a subset of bugs is not beneficial to 
anyone other than spammers. So we can go in either direction:

1. Allow indexers to enumerate bugs, thus indexing all of them.

Seems reasonable that people should be able to find bugs using search engines. 
On the other hand, we'll need to do something to ensure that indexers don't 
destroy Bugzilla performance, and of course spammers will love having more 
flexibility.

2. Block indexing completely.

Seems like no one was bothered by lack of indexing on new bugs so far.

Thoughts?


For reference, here is the current robots.txt content:

$ curl https://bugs.webkit.org/robots.txt
User-agent: *
Allow: /index.cgi
Allow: /show_bug.cgi
Disallow: /
Crawl-delay: 20

- Alexey
- Alexey


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WebCorePrefix.h vs. config.h

[Alexey Proskuryakov]

Hi,

Do we still need separate WebCorePrefix.h and config.h? The former has this 
comment, which I don't think is true any more:

/* This prefix file should contain only:
 *1) files to precompile for faster builds
 *2) in one case at least: OS-X-specific performance bug workarounds
 *3) the special trick to catch us using new or delete without including 
"config.h"
 * The project should be able to build without this header, although we rarely 
test that.
 */

/* Things that need to be defined globally should go into "config.h". */

There are many things that contradict this comment in this file. And even when 
precompiled header is not in use, we include WebCorePrefix.h from config.h 
anyway:

// Using CMake with Unix makefiles does not use prefix headers.
#if PLATFORM(MAC) && defined(BUILDING_WITH_CMAKE)
#include "WebCorePrefix.h"
#endif

I'm mostly looking at some HAVE and ENABLE macros that are in these and should 
be elsewhere, but the confusion between these files bothers me a lot. Should we 
move everything from config.h to WebCorePrefix.h, and only keep config.h just 
to include WebCorePrefix for the lone build scenario where that's needed, and 
to undef new/delete?

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lots of spam on Bugzilla

[Alexey Proskuryakov]

> 4 дек. 2018 г., в 16:45, Ryosuke Niwa  написал(а):
> 
> Alternatively, is there a way you can make more of us be able to moderate 
> these spammers?


Anyone can tag comments to make them invisible, but there is no privilege level 
in Bugzilla where one can disable user accounts, but cannot grant full admin 
privileges.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal for Device-Specific Layout Tests

[Alexey Proskuryakov]

> 4 дек. 2018 г., в 16:43, Ryosuke Niwa  написал(а):
> 
> 
> On Tue, Dec 4, 2018 at 12:55 PM Jonathan Bedard  > wrote:
> These directories would be along-side tests.
> 
> I don't like that platform-specific results are under LayoutTests/platform 
> and device-specific results are next to the tests. We should stick with 
> either convention, not mix them up.
> 
> If we were to match LayoutTests/platforms, we should probably put it under 
> LayoutTests/devices, or alternatively inside each platform's test directory. 
> Alternatively, I'd be fine if we moved platform specific results to those 
> subdirectories. But having both conventions used throughout would be an 
> insane mess.

I'm not ready to have an opinion about which approach is best, however I wanted 
to make a general comment about unification.

I think that the attempt to abstract all sorts of differences behind the "port" 
and "platform" concepts in webkitpy was short sighted. There are many subtle 
and not so subtle variations of behaviors (OS, OS family, specific OS version, 
build style, specific API used from the build when there are multiple options). 
Trying to represent these by god objects is creating a lot more inconsistency 
and confusion than necessary.

One good thing about platform directories is that we can specify inheritance 
order with these in a way that is somewhat meaningful. If we are to have an 
inheritance order for device types, then continuing with the approach would 
make sense. But if the rule is exact match, or best match, then storing them as 
-expected directories makes good sense to me.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lots of spam on Bugzilla

[Alexey Proskuryakov]

> 4 дек. 2018 г., в 11:21, Ryosuke Niwa  написал(а):
> 
> e.g.
> https://bugs.webkit.org/show_bug.cgi?id=168774 
> 
> 
> Is there a way we can integrate CAPTCHA, etc... to prevent these spammers 
> from getting Bugzilla account?

We can integrate CAPTCHA, but based on how the spammers operate, it seems 
unlikely that it would help much. As far as we could find, other Bugzilla 
instances haven't solved this either.

Many of the spam comments look like they were written by humans who skimmed the 
comments above, and there were a couple where the comments looked quite 
convincing at first glance. And the registration process includes sending a 
confirmation link to their e-mail account, which is Gmail most of the time. So 
it's already taking more dedication than passing a CAPTCHA would require.

What I would want to know is what lures spammers to bugzilla. Perhaps we can 
find a way to decrease bugs.webkit.org page rank or whatever makes it a 
valuable target.

- Alexey


> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Design for review: EWS for security bugs

[Alexey Proskuryakov]

> 16 июня 2018 г., в 0:12, Daniel Bates  написал(а):
> 
> Hi all,
> 
> I am working to support EWS processing of patches on security bugs (see 
>  >) and I am writing to this 
> list to solicit feedback on any show-stopper bugs in the proposed design. 
> Historically we have not supported this functionality because the EWS was 
> designed to use Bugzilla as its data store and hence the EWS machines 
> (considered untrusted) would need a Bugzilla account with access to all 
> security bugs. Here is my idea to solve this problem without privileging 
> these machines with full security bug access:
> 
> Have webkit-queues.webkit.org  host copies 
> of security sensitive patches. These patches will be deleted once all EWS 
> queues have processed them. Access to these patches will be guarded by an API 
> key(s) to prevent anonymous access. Each EWS machine will need one. 
> Otherwise, it will skip such patches.
> The tool webkit-patch will now upload a copy of each patch attached to a 
> security bug to webkit-queues.webkit.org  
> as part of submitting a patch to EWS.
> Add a Bugzilla extension to CC the EWS feeder queue on a bug if it has a 
> patch up for review, including security bugs. (The EWS feeder queue is 
> responsible for polling Bugzilla to find unreviewed patches and submitting 
> them to webkit-queues.webkit.org ).
> The EWS feeder queue will now upload a copy of each patch attached to a 
> security bug to webkit-queues.webkit.org  
> as part of submitting a patch to EWS.
> 
> Then EWS machines will be able to process security sensitive patches, report 
> compile-time errors and the list of failing tests. There are three known 
> issues with this approach: 1) EWS bots cannot comment on security bugs 2) EWS 
> bots cannot upload layout test failure tarballs to security bugs and 3) the 
> "Submit for EWS analysis" button will not work. I plan to solve these issues 
> in subsequent bugs. One way to solve the first two issues is to have 
> webkit-queues.webkit.org  store comments 
> and tarballs and teach the EWS feeder queue (or another bot) to submit these 
> comments and upload these tarballs to Bugzilla on behalf of the EWS bots 
> (since the EWS feeder queue has access to the security bug by design decision 
> (3)). To solve the last issue without requiring a person to re-enter their 
> Bugzilla credentials there are at least three approaches: 1) set an 
> appropriate CORS policy for webkit-queues.webkit.org 
>  to access Bugzilla 2) 
> webkit-queues.webkit.org  asks Bugzilla to 
> POST a form back to it or 3) re-implement and host the "Submit for EWS 
> analysis" button on Bugzilla so that it can upload the security sensitive 
> patch to EWS when clicked then redirect to the status-bubbles page on 
> webkit-queues.webkit.org .

I just have a comment about the known issues. Not sure if it makes sense to 
invest effort into addressing these within current design, as we want to stop 
using custom EWS code and move as much as possible to Buildbot.

The stack that EWS is currently built on is very different from anything else 
we use, so it's difficult to maintain.

- Alexey

> I am open to suggestions.
> 
> Dan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Trying to builder older version of webkit (but failing) - looking for help

[Alexey Proskuryakov]

Hello Ted,

603.1.30 is the version included with Safari 10.1 on Sierra, so yes, building 
it against High Sierra SDK with newer Xcode puts you on uncharted territory. 
The file that you are hitting an issue with is one of the first files in 
WebCore to build, so chances are that there will be many other build issues 
later on.

Getting an older macOS version to debug with would likely be a more practical 
approach.

- Alexey

> 22 мая 2018 г., в 3:35, Ted Stresen-Reuter  написал(а):
> 
> (also posted in IRC, but I prefer email)
> 
> Hi. My name is Ted. I am a web application developer. I've got a site done 
> using CSS Grid. Version 10.1.2 (12603.3.8) of Safari has a small issue 
> rendering one page because we didn't explicitly specify grid-template-rows.
> 
> Normally we use browserstack for fixing these types of issues but in this 
> case the page in question is a long and somewhat complex form and it's 
> difficult to debug via browserstack. I found this stackoverflow question that 
> suggests a method for running an older version of Safari but some of the 
> links are now broken.
> 
> https://stackoverflow.com/questions/33423269/is-there-a-way-to-install-emulate-an-older-version-of-safari-i-e-8
>  
> 
> 
> I decided to try building Safari / webkit on a tag that seemed to be roughly 
> the version I needed based on the stackoverflow answer but the build is 
> failing :-(
> 
> I can build other software (AppleScript projects I've worked on and some 
> React Native projects) but webkit just isn't building.
> 
> I am trying to build this exact tag: 
> https://svn.webkit.org/repository/webkit/tags/Safari-603.1.30/ 
> 
> 
> The error I'm getting is:
> 
> The following build commands failed: CompileC {long path reduced for 
> legibility}/AccessibilityImageMapLink.o 
> accessibility/AccessibilityImageMapLink.cpp normal x86_64 c++ 
> com.apple.compilers.llvm.clang.1_0.compiler
> 
> I'm wondering if this version simply won't compile on High Sierra or if I 
> need a specific version of the XCode Cocoa SDK… My XCode version is Version 
> 9.2 (9C40b) 
> 
> No idea… Any pointers would be greatly appreciated.
> 
> Thanks and very kind regards.
> 
> -- 
> Ted Stresen-Reuter
> 
> [t...@secret-source.eu ]
> 
> tel ES: +34 928359902 
> tel UK: +44 (0)2071933739
> Skype: t...@secret-source.eu 
> 
> secret-source.eu 
> 
> Like to know more about us? Check out our promo video: 
> https://vimeo.com/167722524 
> 
> *For out of hours support please email outofho...@secret-source.eu 
>  as my email is only monitored 9-5 Monday 
> toFriday*
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for upgrading xcode toolchains in Apple bots for C++17

[Alexey Proskuryakov]

Hi,

To clarify, are you asking specifically for mac-32bit EWS to be upgraded? It 
has Xcode 9.2, and can be upgraded to 9.3.1 (that will be a multi-step process, 
as we need to keep the version in sync with several other setups). But macOS 
Sierra bots have Xcode 8.3.3, and that is the latest release for Sierra.

- Alexey


> 21 мая 2018 г., в 6:44, Yusuke SUZUKI  написал(а):
> 
> Hi WebKittens, in particular Apple bot maintainers!
> 
> We are about to enable C++17 in all the WebKit ports, and the last step is 
> enabling C++17 for Xcode[1].
> While the latest shipped Xcode (w/ clang) supports C++17 option 
> (`-std=gnu++17`), EWS build bots do not support this. Some build bots accept 
> `-std=c++1z`, this option causes trouble in the latest Xcode (e.g. mac-32bit 
> uses the newer Xcode).
> 
> Can we upgrade Xcodes in EWS and buildbots to the latest ones to accept C++17 
> option? Once it is done, WebKit starts using fancy C++17 features listed in 
> GCC 6.0.
> 
> Best regards,
> Yusuke Suzuki
> 
> [1]: https://bugs.webkit.org/show_bug.cgi?id=185176 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

- Alexey



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Test262 includes some tab characters

[Alexey Proskuryakov]

> 4 февр. 2018 г., в 7:09, Yusuke SUZUKI  написал(а):
> 
> Hi WebKittens,
> 
> Recently, I updated test262, and I found newly added test262 files include 
> TAB characters (\t).
> IIRC, I need some help to import such files into WebKit tree.
> Can we make JSTests/test262 directory free from any SVN style checks?

Yes, one can add an allow-tabs property to bypass the check in pre-commit hook. 
This can be part of the patch.

- Alexey

> Best regards,
> Yusuke Suzuki
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

[Alexey Proskuryakov]

> 12 дек. 2017 г., в 10:58, Mathias Bynens  написал(а):
> 
> Yes, there is such an expectation. jsvu has a policy of only using URLs “that 
> are controlled by the creators of the JavaScript engine”: 
> https://github.com/GoogleChromeLabs/jsvu#security-considerations 
> <https://github.com/GoogleChromeLabs/jsvu#security-considerations>
This is explained as a security policy. If the project considers Igalia builds 
unsafe, how are the same bits copied to another domain by an automated process 
any better?

I'm not necessarily objecting against the copying, but trying to make a 
legitimate story for why any extra work is needed.

- Alexey


> Anything not on *.webkit.org <http://webkit.org/> or similar, or anything not 
> on on S2 buckets that are owned by Apple directly, does not fit that policy.
> 
> On Tue, Dec 12, 2017 at 7:35 PM, Alexey Proskuryakov  <mailto:a...@webkit.org>> wrote:
> 
>> 12 дек. 2017 г., в 1:34, Mathias Bynens > <mailto:m...@google.com>> написал(а):
>> 
>> It would be great to make such downloads available from webkit.org 
>> <http://webkit.org/> or
>> a similar domain!
> 
> 
> Can you explain in more detail why this is important?
> 
> If there is an expectation that this will make the builds more official in 
> some way, then I'd like to understand the difference better. For example, 
> will having links to igalia.com <http://igalia.com/> on webkit.org 
> <http://webkit.org/> work just as well?
> 
> - Alexey
> 
> 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

[Alexey Proskuryakov]

> 12 дек. 2017 г., в 1:34, Mathias Bynens  написал(а):
> 
> It would be great to make such downloads available from webkit.org 
>  or
> a similar domain!


Can you explain in more detail why this is important?

If there is an expectation that this will make the builds more official in some 
way, then I'd like to understand the difference better. For example, will 
having links to igalia.com on webkit.org work just as well?

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

[Alexey Proskuryakov]

> 17 нояб. 2017 г., в 23:02, youenn fablet  написал(а):
> 
> Tests are available at https://w3c-test.org  which 
> makes it easy to share through any tool supporting hyperlinks.
> A webarchive can also be made so that it is easy to share and probably edit 
> such tests.
> Tools like jsfiddle are also a great way to create/share/edit tests.
> I received several bug reports on bugzilla using it and this proved to be 
> efficient.

I don't think that these are applicable verbatim, but there may be some 
solution. Let's find it before assuming that we can have it.

In particular, 
- editing a WebArchive is not really feasible;
- jsfiddle is cool, but I can't just copy a WPT test to jsfiddle to share it.

> Let me explain why I think that WebKit tests are often more valuable as 
> regression tests than WPT tests are. We add tests as we fix bugs, so we know 
> that the tests are generally for problems that have a high impact on users 
> and developers - that's because someone actually discovered the problem, and 
> someone prioritized it highly enough to fix. We also know that our tests 
> cover code that is error prone, which is why we had bugs in the first place. 
> Of course, anything can be broken, but certain things are less likely to. 
> Compliance tests written for specs are also valuable, but at some point we 
> need to prioritize which tests to investigate and even to run.
>  
> I don't really see why we should prioritize the tests to run when all of them 
> provide clear value to some WebKit members.

We prioritize which tests to run all the time, there are whole configurations 
for which we don't run any tests. That's largely because it's not enough to 
simply run the tests - keeping them in a state where they produce actionable 
results requires a lot of attention.

The time it takes to run tests definitely matters a lot for WebKit. So far we 
haven't taken a route like the one Robert mentioned, with a huge amount of 
hardware running shards of tests. There are multiple reasons to that, one of 
those being that we are very interested in finding bugs below WebKit too, and 
having dedicated testers helps with that. When the machine gets into a weird 
state after a few weeks of uptime, it is much easier to start isolating the 
problem when we can see which specific queues are hitting it. It is also much 
easier to reason about data collected by centralized systems, such as crash log 
collection services.

- Alexey


> I agree that we need to prioritize tests we investigate. There can be a 
> solution inside WPT, like adding WebKit specific metadata so that:
> - WPT contributors would communicate with WebKit members whenever changing 
> such tests
> - WebKit contributors would prioritize WPT-WebKit-metadata failing tests
> 
> That said, if these tests are so beneficial to WebKit, they are potentially 
> very useful to other teams as well.
> And vice-versa, we might find really good WPT tests that show useful crashes 
> and failures in WebKit.
> I am experiencing that nowadays with WPT service worker tests.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

[Alexey Proskuryakov]

(re-sending from a correct address)

> 17 нояб. 2017 г., в 9:18, youenn fablet  > написал(а):
> 
> Chris recently noticed that some heavily used files (testharness*) were 
> cacheable through Apache but not WPT.
> This is now fixed and should improve WPT performances.

This is part of >, another part is that the 
server is 10x slower than Apache.

I just tested on my MacBook Pro, and WPT tests took 23% of time while being 
only 9% of the total count. Taking in mind that WebKit own tests have higher 
value due to the way we choose what to test (see below), that's not a great 
story in my opinion.

One other thing that we discussed before was the operational complexity of 
running WPT tests. We frequently need to share tests with people who don't work 
on WebKit directly, but have the need to edit and run our tests. Inability to 
drag and drop a local copy into a Safari window is a deterrent to addressing 
problems caught by the tests. I think that the response we got was that tests 
will continue to require a server to run.

Let me explain why I think that WebKit tests are often more valuable as 
regression tests than WPT tests are. We add tests as we fix bugs, so we know 
that the tests are generally for problems that have a high impact on users and 
developers - that's because someone actually discovered the problem, and 
someone prioritized it highly enough to fix. We also know that our tests cover 
code that is error prone, which is why we had bugs in the first place. Of 
course, anything can be broken, but certain things are less likely to. 
Compliance tests written for specs are also valuable, but at some point we need 
to prioritize which tests to investigate and even to run.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

[Alexey Proskuryakov]

Migrating WebKit tests seems undesirable to me, as that would make us lose all 
their modification history. As mentioned before, WPT tests are inherently 
getting less attention in CI support, largely because of unclear benefit when 
there isn't any history for why the particular test was added.

Regression tests are taking an excessive amount of time to run for us (more 
than 1.5 hours in a debug build), a very large proportion of which is WPT. I do 
not think that the strategy of adopting WPT tests is working well for WebKit.

- Alexey


> 15 нояб. 2017 г., в 2:02, Philip Jägenstedt  написал(а):
> 
> Hello webkit-dev! (ecosystem-infra in Bcc)
> 
> TPAC was last week, and there was much talk about web-platform-tests. Some 
> notes are at 
> https://lists.w3.org/Archives/Public/public-test-infra/2017OctDec/thread.html 
> 
>  and in particular https://www.w3.org/2017/11/07-testing-minutes.html 
> .
> 
> In Blink, we're thinking seriously about what it'd take to upstream large 
> parts of LayoutTests into web-platform-tests, and we've realized that there 
> are some risks here, beyond just making sure the tests are good and per spec. 
> Specifically, one bad outcome would be if Blink successfully upstreamed 
> thousands of tests that are also in WebKit, which then begin to diverge in 
> small and large ways. That'd leave WebKit with more duplication between its 
> own tests and web-platform-tests than any other engine, and a headache that 
> grows over time.
> 
> So, I think this would require close cooperation with the WebKit project. 
> Some different ways this might happen:
> A Blink developer and WebKit developer work together at the same time to move 
> their common tests in some area into web-platform-tests, each removing 
> identical tests that were upstreamed by the other and consolidating what 
> remains.
> A Blink developer works to first upstream tests from WebKit (using WebKit's 
> coming export mechanism), waits for it to be imported into Blink, and then 
> removes the tests from Blink.
> The reverse situation.
> 
> Are there already some areas where the first approach might be doable, where 
> the Blink and WebKit folks already know each other and are eager to do this? 
> Is LayoutTests/css3/flexbox/ by any chance such a case?
> 
> I realize it's hard to judge these approaches in the abstract, but am curious 
> to hear any enthusiasm or concerns about it.
> 
> Thanks!
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Dead code in webkitpy runtests.py

[Alexey Proskuryakov]

I think that we would still like to have a unified way to run tests. Right now, 
even knowing whether a particular script or build step is covered by tests is 
not straightforward.

At the same time, I think that the tiny subset of tests that webkit-patch used 
to run wasn't meaningful. Specifically, those were bindings tests and JSC API 
tests. These make even less sense in the EWS context, as the results were 
ignored if I remember correctly.

- Alexey


> 1 нояб. 2017 г., в 11:01, Aakash Jain  написал(а):
> 
> Hi Everyone,
> 
> Inside webkitpy, in tool/steps/runtests.py there is code to run various kind 
> of tests (JSC, bindings, webkitpy, webkitperl, layout-tests) which seems like 
> dead code. This code is not used by EWS (since ews pass --non-interactive 
> argument to webkit-patch). 
> 
> I believe the original intention of this code was to have a single command to 
> execute all our test-suites. Is there anyone who uses this functionality, by 
> manually running webkit-patch command with "--build-and-test --test" 
> arguments with an intention of running all possible test-suites?
> 
> If not, I am considering to remove this dead code to clean-up webkitpy.
> 
> References: https://bugs.webkit.org/show_bug.cgi?id=178608 
> , 
> https://bugs.webkit.org/show_bug.cgi?id=178599 
> 
> 
> Thanks
> Aakash
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Formatting style for inline comments in Python code

[Alexey Proskuryakov]

> 26 окт. 2017 г., в 10:21, Maciej Stachowiak  написал(а):
> 
> I'm very used to WebKit style for C++, and I agree that we should use PEP8 
> style for Python even where it differs from our C++ style.

We have one PEP8 check that is currently disabled, the one for 79 character 
line length limit. Would you be in favor of changing that, and enforcing the 
line length limit? FWIW, I think that the last time this was discussed was in 
2010, .

The proposal to avoid the two-space comment spacing rule comes from the mindset 
of making webkitpy less isolated from the rest of WebKit code. I certainly hear 
a lot about how difficult it is to hack on. Comment spacing is obviously not 
going to solve this, or even make a noticeable dent, but it does feel like a 
tiny step in the right direction to me.  I'm very interested in hearing what 
obstacles folks who contributed did have to overcome.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Formatting style for inline comments in Python code

[Alexey Proskuryakov]

> 26 окт. 2017 г., в 9:50, Brian Burg  написал(а):
> 
> why differ from the vast majority of all other Python code in existence, just 
> to be different? What's the point?


My point is that people familiar with all other Python code in existence will 
not be hacking on webkitpy. It's WebKit C++ developers who we want to 
contribute to webkitpy more, and super arbitrary differences that are 
impossible to rationalize are an unnecessary barrier to entry.

> If "WebKit developers" want to write Python code, perhaps they should learn 
> the Pythonic idioms of the language

I don't know if many people have the muscle memory to type a different number 
of spaces before a comment. I think that in practice, it's just about more 
iterations before EWS style checker is happy. What are we gaining by this?

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Formatting style for inline comments in Python code

[Alexey Proskuryakov]

> 25 окт. 2017 г., в 18:21, Michael Catanzaro  
> написал(а):
> 
> On Wed, Oct 25, 2017 at 4:58 PM, Aakash Jain  wrote:
>> Does anyone else has any opinion/preference for this?
> 
> The number of spaces before a comment really does not matter, but my $0.02: 
> PEP8 is an extremely common style for Python programs that all Python 
> developers are familiar with. I would follow that, and forget about trying to 
> adapt WebKit C++ style to an unrelated language. Trying to adapt the style 
> checker to ignore particular PEP8 rules seems like wasted effort.


There is definitely a number of PEP8 rules that we want to follow. But I don't 
think that there is anything about the two space before comment rule that makes 
it particularly fitting for Python.

I think that we should target WebKit developers with the coding style as much 
as possible, not Python developers. As we all agree on the one space rule 
elsewhere, why make a part of the code base uncomfortably different for most 
WebKit developers?

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SVN server broken?

[Alexey Proskuryakov]

Is anyone still seeing issues? I see a number of patches landed overnight, 
including by commit queue.

One problem I do see is that trac is stale.

- Alexey


> 8 сент. 2017 г., в 3:19, Carlos Alberto Lopez Perez  
> написал(а):
> 
> On 08/09/17 11:56, Carlos Alberto Lopez Perez wrote:
>> On 08/09/17 04:07, Ling Ho wrote:
>>> We have completed server maintenance works. Please email
>>> ad...@webkit.org if you encounter any problem.
>> 
>> It seems there is an issue with the SVN server?
>> Is rejecting both commits from commit-queue or manually landed.
>> 
>> $ git svn dcommit
>> Committing to http://svn.webkit.org/repository/webkit/trunk ...
>>  D   
>> Tools/wpe/patches/freetype6-2.4.11-truetype-font-height-fix.patch
>>  M   Source/WebCore/ChangeLog
>> 
>> ERROR from SVN:
>> Item is out of date: File '/trunk/Source/WebCore/ChangeLog' is out of date
>> W: 7e9ab8012eb85cca13a55ea65bc0f194c37a11b7 and refs/remotes/origin/master 
>> differ, using rebase:
>> :04 04 a0c128f45219a4f568ffb7b27336ca501b1fc64f 
>> 5f584218e40d75a9c39c52b76fd648459857f264 M   Source
>> :04 04 42e7bcb4148039d4fcc172c267b7db51f0ee98f8 
>> 7faa3cb8917a0bdbd9d0d34942b8d5422ee72eb9 M   Tools
>> Current branch master is up to date.
>> ERROR: Not all changes have been committed into SVN, however the committed
>> ones (if any) seem to be successfully integrated into the working tree.
>> Please see the above messages for details.
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> 
> Also SVN trunk is still at r221777, but on the IRC channel #webkit WKR
> has claimed to have landed r221778 and r221779 (and closed bugs 176252
> and 176303), and I can't see this commits anywhere on the SVN.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Alexey Proskuryakov]

> 30 авг. 2017 г., в 11:55, Andy Estes  написал(а):
> 
 In a completely other direction, what does this mean for use of Xcode? Can 
 we still build from Xcode? Debug?
>>> 
>>> CMake can generate Xcode files, so you can still develop and debug in Xcode.
>> 
>> This annihilates speed up possibility, as xcodebuild will be used instead of 
>> ninja
> 
> I don’t think so. I believe the generated Xcode project uses CMake when 
> building.


Per Keith's original e-mail, the plan is to add native support for unified 
build in WebKit Xcode projects, not relying on CMake in any way.

I have a separate question about the unified build plan though. Are we clear on 
how it will work with using declarations and directives in the global scope of 
.cpp and .mm files? We use these a lot, all over the place.

- Alexey


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Alexey Proskuryakov]

> 12 мая 2017 г., в 16:12, Sam Weinig  написал(а):
> 
> 
> 
>> On May 12, 2017, at 2:49 PM, Alexey Proskuryakov > <mailto:a...@webkit.org>> wrote:
>> 
>> 
>>> 12 мая 2017 г., в 14:38, Sam Weinig >> <mailto:wei...@apple.com>> написал(а):
>>> 
>>> I regret piling on here, as I think this thread has diverged from it’s 
>>> original purpose, but…I understand this frustration. That said, perhaps 
>>> this is something we can solve with some tooling. For instance, a 
>>> run-test-in-safari (as a parallel to run-safari) script could be made which 
>>> starts the server, and then loads the test with the right URL in your built 
>>> Safari (or MiniBrowser, or whatever).  
>> 
>> 
>> That's still not good enough, as this means that I can't point someone else 
>> to an instance of the test on trac.webkit.org <http://trac.webkit.org/> to 
>> reproduce an issue. There is of course be another place to point to when/if 
>> the test gets upstreamed, but even that doesn't support stable links like 
>> trac does.
>> 
>> That's not to mention that learning the name of this proposed script is no 
>> easier than learning about run-webkit-httpd.
>> 
>> - Alexey
>> 
> 
> 
> I’m not sure what you mean by “good enough”.  Good enough for what?  What are 
> we debating here?

I think that I explained it very clearly, but let me try again.

When there is a test failure that I need to communicate to others, I say 
something "please open 
<https://trac.webkit.org/export/216812/webkit/trunk/LayoutTests/fast/images/destroyed-image-load-event.html
 
<https://trac.webkit.org/export/216812/webkit/trunk/LayoutTests/fast/images/border.html>>
 in Safari to reproduce". That's very easy to do, and makes it very easy for 
others to work on the issue.

If your test requires complex setup, like WPT does, then I may not have the 
time to write up complicated steps to reproduce, or the person who gets the bug 
may not have the time to follow them. Those people don't have a WebKit 
checkout, so scripts won't help. This makes the test less effective, as 
problems that it finds are less likely to be addressed.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Alexey Proskuryakov]

> 12 мая 2017 г., в 14:39, Ryosuke Niwa  написал(а):
> 
> This is absolutely not how I operate at all. Since almost all custom
> elements and shadow DOM API tests I wrote are written using
> testharness.js and upstreamed to web-platform-tests, they have been
> deleted from LayoutTests/fast/shadow-dom &
> LayoutTests/fast/custom-elements.
> 
> As such, if any new shadow DOM or custom elements tests under
> LayoutTests/imported/ start to fail, then we must fix them since we
> idon'thave any other test coverage.


I'll try to remember that. I do think that this means that shadow DOM and 
custom elements now have less effective tests, which may result in overlooking 
important issues.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Alexey Proskuryakov]

> 12 мая 2017 г., в 14:38, Sam Weinig  написал(а):
> 
> I regret piling on here, as I think this thread has diverged from it’s 
> original purpose, but…I understand this frustration. That said, perhaps this 
> is something we can solve with some tooling. For instance, a 
> run-test-in-safari (as a parallel to run-safari) script could be made which 
> starts the server, and then loads the test with the right URL in your built 
> Safari (or MiniBrowser, or whatever). 


That's still not good enough, as this means that I can't point someone else to 
an instance of the test on trac.webkit.org to reproduce an issue. There is of 
course be another place to point to when/if the test gets upstreamed, but even 
that doesn't support stable links like trac does.

That's not to mention that learning the name of this proposed script is no 
easier than learning about run-webkit-httpd.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Alexey Proskuryakov]

> 12 мая 2017 г., в 11:52, Ben Kelly  написал(а):
> 
> On Fri, May 12, 2017 at 2:26 PM, Rick Byers  <mailto:rby...@chromium.org>> wrote:
> On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov  <mailto:a...@webkit.org>> wrote:
> Since imported WPT tests are very flaky, and are not necessarily written to 
> defend against important regressions, investigating issues with them is 
> relatively lower priority than investigating issues observed with WebKit 
> tests. So I would recommend not mixing tests for WebKit regressions with WPT 
> tests - if your test eventually ends up in LayoutTests/imported, it will 
> become a lot less effective.
> 
> FWIW this is absolutely NOT how we're treating this in chromium.  If this is 
> how things end up in practice then we will have failed massively in this 
> effort.
> 
> We figure if we want the web to behave consistently, we really have no choice 
> but to treat web-platform-tests as first class with all the discipline we 
> give to our own tests.  As such we are actively moving 
> <https://codereview.chromium.org/2877673004> many of our LayoutTests to 
> web-platform-tests and depending entirely on the regression prevention they 
> provide us from there.  Obviously there will be hiccups, but because our 
> product quality will depend on web-platform-tests being an effective and 
> non-flaky testsuite (and because we're starting to require most new features 
> have web-platform-tests before they ship), I'm confident that we've got the 
> incentives in place to lead to constant ratcheting up the engineering 
> discipline and quality of the test suite.
> 
> FWIW, mozilla also treats WPT as first class tests.  We're not actively 
> moving old tests to WPT like google, but all new tests (at least in DOM) are 
> being written in WPT.  Of course, we do have exceptions for some tests that 
> require gecko-specific features (forcing GC, etc).


We don't have a concept of "first class", but I hope that when choosing between 
looking into a simple test that was added for a known important bug, and 
looking into an imported test whose importance is unclear, any WebKit engineer 
will pick the former. And since no one can fix all the things, such 
prioritization makes imported tests less effective.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Alexey Proskuryakov]

> 9 мая 2017 г., в 11:27, Simon Fraser  написал(а):
> 
> Another consideration here is "would my test be useful for other browser 
> vendors". I don't think the answer is a unanimous "yes", so I think we should 
> only use WPT for tests that will think are worth sharing.

Since imported WPT tests are very flaky, and are not necessarily written to 
defend against important regressions, investigating issues with them is 
relatively lower priority than investigating issues observed with WebKit tests. 
So I would recommend not mixing tests for WebKit regressions with WPT tests - 
if your test eventually ends up in LayoutTests/imported, it will become a lot 
less effective.

Using the complicated harness has a similar consequence - if you use any WPT 
goodies like templates or server side scripts, the cost of investigating issues 
on the test increases, and makes the test less valuable.

I don't know if there is any way to adopt WPT that won't make testing less 
effective. WPT tests may be useful in very rare cases, where we actively want 
to communicate certain subtle behavior details to other vendors - but even so, 
I imagine that other vendors may not put high priority on those, for the same 
reasons.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Commits in branches triggering build in the bots now

[Alexey Proskuryakov]

Hi Carlos,

Could you please file a bug, and include the relevant links to investigate the 
issue?

- Alexey


> 4 мая 2017 г., в 0:46, Carlos Garcia Campos  написал(а):
> 
> I don't know what have changed, but now, commits in other branches are
> triggering builds in the bots. I have just realized after merging a
> couple of commits in GTK+ stable branch. This didn't happen before,
> those commits didn't show in the bots at all. 
> 
> Any idea why is this happening now? I don't see any relevant change in
> the buildbot config. For now I'll stop merging commits because I don't
> want the bots to waste the time building and running tests when nothing
> has actually changed.
> 
> Thanks, 
> Carlos Garcia Campos
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Aakash Jain is now a WebKit Reviewer

[Alexey Proskuryakov]

Hi everyone,

I would like to announce that Aakash Jain is now a WebKit reviewer. Aakash 
works on WebKit tools and infrastructure. Please join me in congratulating 
Aakash, and send him some patches to review!

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unable to log in to bugs.webkit.org

[Alexey Proskuryakov]

Done.

If anyone else hits this, please e-mail ad...@webkit.org 
. Resetting the password did work for other people, so 
clearly there is some flakiness to diagnose.

- Alexey

> 1 апр. 2017 г., в 10:24, Dan Bernstein  написал(а):
> 
> Can someone help me log in to by bugs.webkit.org  
> account?
> 
> I logged out of bugs.webkit.org  and now when I try 
> to log in with my email m...@webkit.org , an error 
> message appears saying that I must request a new password. When I click the 
> “request a new password” link, I receive two email messages in rapid 
> succession. The first one includes a password change link. The second one 
> says that the password change  has been canceled because I requested 
> cancellation. After that, the link from the first email is useless.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Bugzilla 5.0.3 password strength requirements

[Alexey Proskuryakov]

Hi,

Our updated Bugzilla installation now has password strength check enabled. It 
will refuse logging in with a weak password.

One specific tool that is affected is webkit-patch, which logs in every time. 
If it's giving you strange errors like the below, please try logging out from 
Bugzilla using browser UI, and logging back in again. If the password is 
considered weak, it will tell how to reset it.

Traceback (most recent call last):
  File "/OpenSource/Tools/Scripts/webkit-patch", line 84, in 
main()
  File "/OpenSource/Tools/Scripts/webkit-patch", line 79, in main
WebKitPatch(os.path.abspath(__file__)).main()
  File "/OpenSource/Tools/Scripts/webkitpy/tool/multicommandtool.py", 
line 305, in main
result = command.check_arguments_and_execute(options, args, self)
  File "/OpenSource/Tools/Scripts/webkitpy/tool/multicommandtool.py", 
line 123, in check_arguments_and_execute
return self.execute(options, args, tool) or 0
  File 
"/OpenSource/Tools/Scripts/webkitpy/tool/commands/abstractsequencedcommand.py",
 line 55, in execute
self._sequence.run_and_handle_errors(tool, options, state)
  File 
"/OpenSource/Tools/Scripts/webkitpy/tool/commands/stepsequence.py", line 
73, in run_and_handle_errors
self._run(tool, options, state)
  File 
"/OpenSource/Tools/Scripts/webkitpy/tool/commands/stepsequence.py", line 
67, in _run
step(tool, options).run(state)
  File "/OpenSource/Tools/Scripts/webkitpy/tool/steps/postdiff.py", line 
50, in run
self._tool.bugs.add_patch_to_bug(bug_id, diff, description, 
comment_text=comment_text, mark_for_review=self._options.review, 
mark_for_commit_queue=self._options.request_commit)
  File 
"/OpenSource/Tools/Scripts/webkitpy/common/net/bugzilla/bugzilla.py", 
line 633, in add_patch_to_bug
self.browser.select_form(name="entryform")
  File 
"/OpenSource/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_mechanize.py",
 line 524, in select_form
raise FormNotFoundError("no form matching "+description)
webkitpy.thirdparty.autoinstalled.mechanize._mechanize.FormNotFoundError: no 
form matching name 'entryform'


- Alexey



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] DEFERRED: Scheduled Outage: WebKit Bugzilla (bugs.webkit.org) March 13th, 2017 from 9AM PDT to Noon PDT

[Alexey Proskuryakov]

Hi,

The upgrade was deferred to a later date.

There will be svn.webkit.org  maintenance with some 
downtime on Monday afternoon. The exact time will be announced on Monday.

- Alexey

> 8 марта 2017 г., в 11:49, Ling Ho  > написал(а):
> 
> Hi,
> 
> We have scheduled an outage for upgrading Bugzilla (bugs.webkit.org 
> ) to version 5.0.3 on Monday, March 13th, 2017 from 
> 9AM PDT to Noon PDT. Please be informed and plan accordingly.
> 
> Please let me know if you have any questions or concerns.
> 
> Thanks,
> ...
> ling
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can I get the editbugs-bit?

[Alexey Proskuryakov]

Done.

- Alexey

> 1 марта 2017 г., в 17:15, Suzuki, Basuke  
> написал(а):
> 
> Hi
>  
> My name is Basuke Suzuki, working at SONY Interactive Entertainment, a.k.a 
> PlayStation,
> working with Don Olmstead and Hironori Fujii
>  
> I want to ask to assign the editbugs-bit on me.
>  
> I have started to commit WebKit repository since last month. I filed some 
> bugs and
> also some of my fixes have already landed.
>  
> Bug 168486 – [WinCairo][MiniBrowser] Add ca-bundle to display secure pages 
> 
> Bug 134340 – curl: Improve errors by including the domain 
> 
> Bug 168843 – Windows build doesn’t start build if the git branch is not 
> master 
> Bug 168345 – [CURL] ResourceError created with error information should have 
> default type Type::General 
>  
> Regards,
>  
> Basuke Suzuki
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SVN trouble

[Alexey Proskuryakov]

Fixed bugmail, thank you for pointing it out. No e-mails should be lost, they 
were queued for delivery.

- Alexey

> 26 февр. 2017 г., в 11:36, Chris Dumez  написал(а):
> 
> It also seems bugzilla mail notifications may be down.
> 
> Chris Dumez
> 
> On Feb 25, 2017, at 8:40 AM, Simon Fraser  <mailto:simon.fra...@apple.com>> wrote:
> 
>> EWS is still down. Do we have an ETA?
>> 
>> Simon
>> 
>>> On Feb 24, 2017, at 10:25 PM, Alexey Proskuryakov >> <mailto:a...@webkit.org>> wrote:
>>> 
>>> 
>>>> 24 февр. 2017 г., в 19:50, Chris Dumez >>> <mailto:cdu...@apple.com>> написал(а):
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Feb 24, 2017, at 11:41 AM, Alexey Proskuryakov >>>> <mailto:a...@webkit.org>> wrote:
>>>>> 
>>>>> I believe that all infrastructure has recovered. We are currently looking 
>>>>> into one unrelated issue with webkit-queues, so EWS and commit queue 
>>>>> don't work.
>>>>> 
>>>>> - Alexey
>>>> 
>>>> 
>>>> It looks like EWS is still down. Did it break again or is it just not 
>>>> fixed yet?
>>> 
>>> 
>>> It did work for a period of time, but no conclusive fix yet.
>>> 
>>> - Alexey
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SVN trouble

[Alexey Proskuryakov]

> 24 февр. 2017 г., в 19:50, Chris Dumez  написал(а):
> 
> 
> 
> 
>> On Feb 24, 2017, at 11:41 AM, Alexey Proskuryakov > <mailto:a...@webkit.org>> wrote:
>> 
>> I believe that all infrastructure has recovered. We are currently looking 
>> into one unrelated issue with webkit-queues, so EWS and commit queue don't 
>> work.
>> 
>> - Alexey
> 
> 
> It looks like EWS is still down. Did it break again or is it just not fixed 
> yet?


It did work for a period of time, but no conclusive fix yet.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SVN trouble

[Alexey Proskuryakov]

From my testing, bot git.webkit.org and git-svn work now.

The only thing I did was block access to 
cache/disk-cache/resources/shattered-2.pdf using authz (this is the file with 
collision). I think that the reason why mirrors only updated now is that 
someone committed to trunk, and thus invoked post-commit hooks.

I believe that all infrastructure has recovered. We are currently looking into 
one unrelated issue with webkit-queues, so EWS and commit queue don't work.

- Alexey


> 24 февр. 2017 г., в 11:29, Carlos Alberto Lopez Perez  
> написал(а):
> 
> On 24/02/17 20:16, Alexey Proskuryakov wrote:
>> 
>> How does one create a local git-svn checkout to try this out? Given that
>> the offending file has been effectively deleted from svn, I think that
>> git-svn should work too.
> 
> You have the script:
> Tools/Scripts/webkit-patch setup-git-clone
> 
> And there is more doc here:
> https://trac.webkit.org/wiki/UsingGitWithWebKit
> 
> I can confirm that now it seems to work :) Thanks.
> 
> Also the git mirror is now updated beyond r212951.
> 
> How do you fixed this?
> 
> I see now that the files on r212951 have different sha1 hashes:
> 
> $ svn co 
> https://svn.webkit.org/repository/webkit/trunk/LayoutTests/http/tests/cache/@r212951
> 
> $ find cache/|grep pdf|xargs sha1sum
> 1880d3e60a5f888c5eb077dd6c52a9a80423d971  
> cache/disk-cache/resources/shattered-1-nocollision.pdf
> 38762cf7f55934b34d179ae6a4c80cadccbb7f0a  
> cache/disk-cache/resources/shattered-1.pdf
> 682ca0c01721fe5e49a91da2253b4aa2fe2cde1c  
> cache/disk-cache/resources/shattered-2-nocollision.pdf
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SVN trouble

[Alexey Proskuryakov]

> 24 февр. 2017 г., в 9:31, Carlos Alberto Lopez Perez  
> написал(а):
> 
> On 24/02/17 18:08, Alexey Proskuryakov wrote:
>> works. There is almost certainly more cleanup that needs to be done - I
>> can see that trac.webkit.org <http://trac.webkit.org> is broken. Please

Trac works now.

> git-svn is broken


How does one create a local git-svn checkout to try this out? Given that the 
offending file has been effectively deleted from svn, I think that git-svn 
should work too.

- Alexey


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SVN trouble

[Alexey Proskuryakov]

> 24 февр. 2017 г., в 7:48, Antti Koivisto  написал(а):
> 
> Hi,
> 
> Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 
>  caused some sort of SVN 
> problem. Please hold commits until this is resolved.

I deleted the remaining PDF file from resources, so svn checkout now works. 
There is almost certainly more cleanup that needs to be done - I can see that 
trac.webkit.org  is broken. Please reply to the thread 
about what else you see not working.

- Alexey



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Upstreaming Tests from WebKit to Web Platform Tests

[Alexey Proskuryakov]

> 6 февр. 2017 г., в 12:28, Ryosuke Niwa  написал(а):
> 
> The concern I've heard about is not how run-webkit-tests run the tests. It's 
> about how a test is opened inside a browser, DRT, WTR while debugging.

+1

I think that making web platform tests more practical for engineers to work 
with should be a pre-requisite for deeper integration.

From tools perspective, cleaning up the way we get supporting scripts for web 
platform tests would be quite beneficial too. It is very hard to reason about 
what happens in a merge that just updates .tar.gz files or a SHA hash.

- Alexey


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Alexey Proskuryakov]

There are two considerations which make me skeptical that auto is a good thing.

1. There are many smart pointer types in C++, and ignoring pointer types is 
very error prone. Others have mentioned std::optional, and mistakes being made 
with RefPtrs. I even saw a case where a review comment that suggested switching 
to auto, but it would have introduced memory corruption if followed.

Some specific cases of this may become irrelevant as PassRefPtr goes away, but 
I don't think that there is any expectation that smart pointers in general are 
going away.

2. I also find that types in code are an important part of documenting how it 
is supposed to work. In a way, these are read-time assertions. An assertion can 
be wrong and they are compiled out in release builds, yet they prove to be 
highly valuable anyway. Similarly, a type can be wrong, but it tells me as the 
reader what the author thinks their code is doing, and lets me focus on other 
parts of it for the first pass at least.

A very similar kind of type agnostic coding has always been used in templates, 
and it feels like a well established belief that it takes engineers with high 
levels of expertise to write generic code in templates. And if it's harder, I 
don't see why using these techniques all over the place is beneficial.

- Alexey


> 11 янв. 2017 г., в 9:15, Darin Adler  написал(а):
> 
> OK, you didn’t convince me but I can see that your opinions here are strongly 
> held!
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Asserting versus throwing in internals and testRunner objects

[Alexey Proskuryakov]

Note that we are talking about API misuse here, so associating the crash with a 
test is not really needed - it's the test that you are writing.

I've seen tests getting checked in even when they don't run to completion and 
raise JS exceptions. I want it to be very clear and obvious when a test is bad, 
and a console log is too subtle of a clue. Additionally, I don't really see 
much difference between these asserts that we use in TestRunner and asserts in 
shipping code. Both are about unexpected conditions, so if we want to avoid 
crashing, shouldn't we also convert all ASSERTs into log messages?

Ultimately, I don't think that it is fair to think about testRunner and tests 
themselves as separate entities, which is of course the way we think about 
WebKit and web content. Tests are designed with testRunner limitations in mind, 
and if these limitations are not respected, the response should be the same as 
for any expectation mismatch between C++ functions. Making the connection 
weaker will make it harder to maintain the tests.

- Alexey


> 23 сент. 2016 г., в 16:26, Geoffrey Garen  написал(а):
> 
> I vote for throwing a JS exception.
> 
> In my experience, tests that crash are harder to deal with than tests that 
> throw JS exceptions. A backtrace is a less informative than the message “you 
> called internals.X without a frame”. Symbolication takes a long time. And 
> sometimes we have trouble associating crash logs with specific tests.
> 
> Geoff
> 
>> On Sep 23, 2016, at 2:25 PM, Ryosuke Niwa  wrote:
>> 
>> Hi all,
>> 
>> In https://bugs.webkit.org/show_bug.cgi?id=161919, a question was
>> raised as to what would be the best practice when one of internals or
>> testRunner method is called at an undesirable timing or wrong
>> arguments.  The case in question was about calling it on a document
>> without a frame when the method required a frame.
>> 
>> What would be the desired outcome of making such a method call?
>> Should we be asserting it and crashing the process?  Or should we be
>> throwing an exception?
>> 
>> - R. Niwa
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] "Fake" ref-tests

[Alexey Proskuryakov]

> 22 июля 2016 г., в 22:34, Darin Adler  написал(а):
> 
>> On Jul 22, 2016, at 10:25 PM, Alexey Proskuryakov  wrote:
>> 
>> Simon and I were trying to move all tests out of platform/ directories.
> 
> Is this nearly done? Can we take that feature out of the test running script?

There are 236 .html files in LayoutTests/platform/ at this time, and a few 
tests of other types.

https://bugs.webkit.org/show_bug.cgi?id=147586 Move tests out of platform 
directories
https://bugs.webkit.org/show_bug.cgi?id=147587 check-webkit-style should warn 
about tests in platform directories

- Alexey

> Anyone have any objections to this?
> 
> — Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] "Fake" ref-tests

[Alexey Proskuryakov]

> 22 июля 2016 г., в 21:57, Darin Adler  написал(а):
> 
>> What is the right way to deal with tests like these?
> 
> I think we should move the tests into platform/mac.

Simon and I were trying to move all tests out of platform/ directories. When 
the expected results are different across OS versions, or between WebKit1 and 
WebKit2, it gets really confusing where to put the expected results.

As much as possible, platform specific tests should be in directories named 
after a specific technology that's skipped on platforms that don't have it. In 
this case where it's just platform specific, fast/borders/mac would work best I 
think.

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ./Tools/Scripts/run-safari doesn't work with Safari 10

[Alexey Proskuryakov]

Hello Marco,

> 18 июля 2016 г., в 13:02, Marco Barisione  
> написал(а):
> 
> Hello,
> 
> I recently installed Safari 10 on some machines running 10.11.6 DP. 
> Unfortunately, I cannot get Safari 10 to work with WebKit compiled from SVN.
> 
> I tried with both SVN trunk (from today) and the revision tagged in SVN that 
> corresponds to my currently installed Safari (602.1.38.4).
> I compiled Safari with the usual:
> 
>  $ ./Tools/Scripts/build-webkit
> 
> And then I tried to run Safari with:
> 
>  $ ./Tools/Scripts/run-safari
> 
> Safari 10 starts, but nothing loads probably because it cannot load its 
> injected bundle. This is the output:
> 
> Starting SafariForWebKitDevelopment with DYLD_FRAMEWORK_PATH set to point to 
> built WebKit in /Users/bari/src/webkit/WebKitBuild/Release.
> 2016-07-18 14:18:32.900 SafariForWebKitDevelopment[424:4918] [Keychain] 
> SecItemCopyMatching failed fetching extension list with error -34018
> 2016-07-18 14:18:32.923 SafariForWebKitDevelopment[424:4918] [Keychain] 
> SecItemCopyMatching failed fetching extension list with error -34018
> 2016-07-18 14:18:33.091 com.apple.WebKit.WebContent.Development[425:4983] 
> Error loading 
> /System/Library/StagedFrameworks/Safari/Safari.framework/Safari:  
> dlopen(/System/Library/StagedFrameworks/Safari/Safari.framework/Safari, 265): 
> Symbol not found: _OBJC_CLASS_$_WBSCompletionListRankingObserver
>  Referenced from: 
> /System/Library/StagedFrameworks/Safari/Safari.framework/Safari
>  Expected in: 
> /System/Library/PrivateFrameworks/SafariShared.framework/Versions/A/SafariShared
> in /System/Library/StagedFrameworks/Safari/Safari.framework/Safari
> InjectedBundle::load failed - Could not load the executable from the bundle.

There are a couple things that look unexpected to me here. Since it's about 
Safari 10, could you please file a bug at https://bugreport.apple.com, 
attaching a sysdiagnose ("sudo sysdiagnose" in Terminal)?

Please feel free to e-mail me the bug number to take a look.

- Alexey



> 
> I’m a bit surprised that I couldn’t find anything about this problem in 
> bugzilla, IRC or on this mailing list.
> Am I doing something wrong or is this a problem with newer Safari? Is there 
> any fix/workaround for this?
> 
> Thank you!
> 
> -- 
> Marco Barisione
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] How to deal with 1-pixel differences in reftests ?

[Alexey Proskuryakov]

> 18 нояб. 2015 г., в 11:50, Simon Fraser  написал(а):
> 
> There are some well-understood reasons why a test might not exactly match its 
> reference. One is that the test uses compositing layers to do clipping, but 
> the reference just clips with drawing, and these are not expected to give a 
> pixel-perfect match.
> 
> I proposed a way to allow a test to specify a custom tolerance in 
> https://bugs.webkit.org/show_bug.cgi?id=149828 
> . If we had this, it would 
> allow me to fix 142258  and 
> 146523 .

Bug 142258 also serves as an example for why we shouldn't do this. Both known 
reasons for it are actual bugs that needed to be discovered, and need to be 
fixed.

What are the causes for flakiness in bug 146523?

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] How to deal with 1-pixel differences in reftests ?

[Alexey Proskuryakov]

Hi,

I do not think that there is a way to algorithmically define what an acceptable 
difference is. Here are a few cases where it's critical to detect small 
differences:

- color management, e.g. testing different code paths that should match 
precisely;
- finding uninitialized memory use bugs in rendering pipeline, which do cause 
minor pixel noise;
- testing antialiasing and scaling behavior (e.g. that we should revert to high 
quality scaling after an animation is done);
- testing text rendering, where the difference can easily be small, e.g one 
accent over one letter on a mostly blank test result.

Talking from past experience that we had with pixel test tolerance and with 
retrying failing tests, I believe that leeway in reporting failures quickly 
causes significant deterioration in infrastructure quality, up to a point where 
we can't tell what's going on with many tests.

- Alexey



> 18 нояб. 2015 г., в 4:36, Carlos Alberto Lopez Perez  
> написал(а):
> 
> Hi,
> 
> Some reference tests give a 1-pixel or very few pixel differences [1].
> 
> I'm not sure if this really indicates a problem in the WebKit code, or
> it indicates that we are just too strict not allowing even a very small
> percentage in pixel differences for this kind of tests.
> 
> Should we tolerate a few pixel differences for reftests ?
> 
> I have done some tests, and the test in [1] passes for any value of
> tolerance >= 0.1% (with the GTK port).
> 
> I'm inclined to allow a very small value, for example a 0.001% (that
> would be 100 times stricter than the tolerance value we use for the
> other tests)
> 
> 
> Regards
> ---
> 
> [1]
> 
> For example, this is happening in the GTK port:
> https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r192415%20%2812243%29/imported/blink/fast/canvas/canvas-clip-stack-persistence-diffs.html
> The diff image normalized (so you can see where is the diff):
> http://people.igalia.com/clopez/wkbug/151261/canvas-clip-stack-persistence-diff_normalized.png
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev]

[Alexey Proskuryakov]

Hello Yoav,

Is there any technology on the horizon that would simplify doing this kind of 
optimization? If done manually, this seems:
- complicated, so only a few sites will do this;
- very likely to go stale, as the content changes, but preload instructions do 
not get updated;
- related to the above, the failure mode is opaque, as the website will only 
get a little slower to load, and not break functionally.

Sending the preload requests in HTTP response headers seems like it would 
provide the most benefit, but is also more prone to the above issues.

Preloading resources as untyped data doesn't seem like a good match to the 
loader implementation mostly dealing with typed resources. Additionally, 
fetching depends on the referring document's properties (notably the charset is 
inherited for same origin subresources). This is not necessarily a blocker, but 
the proposal adds a different way to think about subresource loading.

There appears to be some feature duplication with HTTP/2 server push 
functionality, could you please characterize the differences that would make it 
worth having both?

- Alexey


> 11 нояб. 2015 г., в 6:11, Yoav Weiss  написал(а):
> 
> Hi,
> 
> I'm interested in adding support for  
>  and the corresponding "Link:" headers and 
> wanted to gauge interest for supporting the feature.
> 
> The preload relationship provides a declarative fetch primitive that enables 
> developers to initiate a resource fetch and separate fetching from resource 
> execution. As such, preload is a low-level primitive that enables 
> applications to build custom resource loading and execution behaviors without 
> hiding resources from the user agent and incurring delayed resource fetching 
> penalties. 
> 
> Use cases include:
> * Early fetch of lately discovered critical resources - Sites that contain 
> critical resources that aren't discoverable by the preload scanner (e.g. 
> fonts, JS loaded scripts and styles, etc) can use the feature to download 
> these critical resources early
> * Separation of download and execution in a declarative, non-hacky way.
> 
> All in all, it would enable Web sites to significantly improve loading 
> performance in various common scenarios.
> 
> Thanks!
> Yoav
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Windows EWS not working?

[Alexey Proskuryakov]

(re-sending from the right e-mail address for the list)

> 7 нояб. 2015 г., в 16:56, Darin Adler  написал(а):
> 
> I was looking at the patch in this bug:
> 
> https://bugs.webkit.org/show_bug.cgi?id=150967
> 
> The patch was posted 20 hours ago. EWS has processed this for all platforms 
> other than Windows, but it says “win #61”, so it seems like the Windows bot 
> has 60 other patches to process before getting to this one.
> 
> Does this mean the Windows EWS is stuck? Who can get it unstuck?

Yes, Windows EWS bots fail to start with the below error. I think that this is 
a regression from , so Daniel Bates 
has volunteered to look into this.

Starting Queue
Traceback (most recent call last):
 File "/home/buildbot/WebKit/Tools/Scripts/webkit-patch", line 84, in 
   main()
 File "/home/buildbot/WebKit/Tools/Scripts/webkit-patch", line 79, in main
   WebKitPatch(os.path.abspath(__file__)).main()
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/multicommandtool.py", 
line 305, in main
   result = command.check_arguments_and_execute(options, args, self)
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/multicommandtool.py", 
line 123, in check_arguments_and_execute
   return self.execute(options, args, tool) or 0
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/commands/queues.py", 
line 153, in execute
   return engine(self.name, self, self._tool.wakeup_event, 
self._options.seconds_to_sleep).run()
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/bot/queueengine.py", 
line 91, in run
   self._delegate.begin_work_queue()
 File 
"/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/commands/earlywarningsystem.py",
 line 56, in begin_work_queue
   self._layout_test_results_reader = LayoutTestResultsReader(self._tool, 
self._port.results_directory(), self._log_directory())
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/port/base.py", line 777, in 
results_directory
   option_val = self.get_option('results_directory') or 
self.default_results_directory()
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/port/base.py", line 791, in 
default_results_directory
   return self._build_path('layout-test-results')
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/port/win.py", line 134, 
in_build_path
   root_directory = self._filesystem.join(self.get_option('root'), 
binary_directory)
 File 
"/home/buildbot/WebKit/Tools/Scripts/webkitpy/common/system/filesystem.py", 
line 151, in join
   return os.path.join(*comps)
 File "/usr/lib/python2.7/posixpath.py", line 77, in join
   elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Mac EWS Updates!

[Alexey Proskuryakov]

Normally, we try to configure EWS with OS versions that most engineers no 
longer use on their machines, to maximize the chances of catching problems that 
one can't catch locally.

It would certainly be ideal to cover the full spectrum, as many contributors 
don't have Macs at all.

- Alexey

> 20 окт. 2015 г., в 22:54, Ryosuke Niwa  написал(а):
> 
> Great!  Are you also planning to replace those Mavericks EWS bots with
> El Capital bots?
> - R. Niwa
> 
> 
> On Wed, Oct 21, 2015 at 7:24 AM, Lucas Forschler  wrote:
>> Hello everyone!
>> 
>> Apple has added two new EWS queues to our infrastructure.
>> Alongside our iOS, mac, and mac-wk2 queues, you will now see the following
>> two additions: mac-debug & mac-32bit
>> 
>> This puts our current EWS configuration as follows:
>> 
>> iOS:
>> ARMv7 Release (build only)
>> mac:
>> Mavericks 64-bit WK1 Release (build and test)
>> mac-wk2:
>> Mavericks 64-bit WK2 Release (build and test)
>> mac-debug:
>> Yosemite 64-bit Debug (build and test)
>> mac-32bit:
>> Yosemite 32-bit Release (build only)
>> 
>> Please watch your patches for results on the new queues!
>> 
>> Thanks,
>> Lucas
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bugzilla default assignees

[Alexey Proskuryakov]

Yet another approach used by the Accessibility component is to have a technical 
account auto-CC'ed, and then anyone interested can follow this account. This 
seems like the most reliable solution to me.

- Alexey



14 сент. 2015 г., в 9:26, Brian Burg  написал(а):

> It should be possible for an administrator to set a component's default 
> assignee and default cc: list. We use the default-cc approach for the Web 
> Inspector component (though it often goes out of date).
> 
> However, the default assignee approach seems nice from a self-service POV, 
> and we don’t seem to rely on the assignee field too much in the WebKit 
> bugzilla. What do others think?
> 
> Brian
> 
>> On Sep 12, 2015, at 4:48 PM, Michael Catanzaro  wrote:
>> 
>> Hi,
>> 
>> In WebKit Bugzilla the default assignee for all bugs is Nobody. This is
>> problematic because it makes it really hard to notice when new bugs are
>> filed against a particular component. For example, I want to be CCed on
>> all new bugs in the WebKit Gtk component. If there was a fake default
>> assignee, say webkit-gtk-ma...@webkit.bugs, then I could just add that
>> email to the User Watching section under my Email Preferences, and I'd
>> notice whenever a bug in that component is filed or changes state. This
>> is what we do in GNOME Bugzilla and it works quite well.
>> 
>> Since we don't have that, what I've been doing is watching Carlos
>> Garcia, which is a decent approximation since he tends to get CCed on a
>> lot of bugs. :) But only regular contributors know to CC him, so if the
>> bug isn't filed by a regular contributor, nobody ever sees it.
>> 
>> If a Bugzilla admin could set up default assignees for the various
>> components (or at least the WebKit Gtk component, but it would be
>> useful for all of them), that would be awesome.
>> 
>> Thanks,
>> 
>> Michael
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

- Alexey


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Commit queue issues

[Alexey Proskuryakov]

> 2 сент. 2015 г., в 9:59, Alexey Proskuryakov  написал(а):
> 
> 
> 02 сент. 2015 г., в 5:41, Philippe Normand  написал(а):
> 
>> It seems the commit queue cannot land patches?
>> 
>> https://bugs.webkit.org/show_bug.cgi?id=148702
> 
> This should be resolved now. I see that you already marked this patch for cq+ 
> again; I'll see if any others are stuck.

The issue re-occurred later in the day, and should be really resolved now. Many 
thanks to everyone who worked on fixing it!

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Commit queue issues

[Alexey Proskuryakov]

02 сент. 2015 г., в 5:41, Philippe Normand  написал(а):

> It seems the commit queue cannot land patches?
> 
> https://bugs.webkit.org/show_bug.cgi?id=148702

This should be resolved now. I see that you already marked this patch for cq+ 
again; I'll see if any others are stuck.

- Alexey



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard [Caution: Message contains Suspicious URL content]

[Alexey Proskuryakov]

I tried running the style queue from command line, and it processed some 
patches, errored out on some others, and then hit a different error. 

I restarted the queue normally then, and it has processed all patches except 
for . We 
probably need to find a way to enable more logging to find the problem(s). 
Looks like the bot has trouble talking to bugzilla.

Running WebKit style-queue.
Starting Queue
Logging in as commit-qu...@webkit.org...
Fetching: https://bugs.webkit.org/attachment.cgi?id=257909&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147484&ctype=xml&excludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257909&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147484&ctype=xml&excludefield=attachmentdata
Error: style-queue did not process patch.
Releasing work item 257909 from style-queue
Unable to process work item.
Fetching: https://bugs.webkit.org/attachment.cgi?id=257916&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147486&ctype=xml&excludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257916&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147486&ctype=xml&excludefield=attachmentdata
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style clean
Cleaned working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style update
Updated working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-attachment --no-update --non-interactive 257916
Applied patch
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-watchlist-local 147486
Watchlist applied
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style check-style-local --non-interactive --quiet
Style checked
Pass
Releasing work item 257916 from style-queue
Fetching: https://bugs.webkit.org/attachment.cgi?id=257917&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147297&ctype=xml&excludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257917&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147297&ctype=xml&excludefield=attachmentdata
Error: style-queue did not process patch.
Releasing work item 257917 from style-queue
Unable to process work item.
Fetching: https://bugs.webkit.org/attachment.cgi?id=257832&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147107&ctype=xml&excludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257832&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147107&ctype=xml&excludefield=attachmentdata
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style clean
Cleaned working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style update
Updated working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-attachment --no-update --non-interactive 257832
Applied patch
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-watchlist-local 147107
Watchlist applied
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style check-style-local --non-interactive --quiet
Style checked
Pass
Releasing work item 257832 from style-queue
Fetching: https://bugs.webkit.org/attachment.cgi?id=257918&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147487&ctype=xml&excludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257918&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147487&ctype=xml&excludefield=attachmentdata
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style clean
Cleaned working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style update
Updated working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-attachment --no-update --non-interactive 257918
Applied patch
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-watchlist-local 147487
Watchlist applied
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style check-style-local --non-interactive --quiet
Style checked
Pass
Releasing work item 257918 from style-queue
Fetching: https://bugs.webkit.org/attachment.cgi?id=257919&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147488&ctype=xml&excludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257919&action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147488&ctype=xml&excludefield=attachmentdata
Error: style-queue did not process patch.
Releasing w

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

[Alexey Proskuryakov]

Hi,

Which are the bots that you found missing?

I don't expect any changes to how frequently the dashboard code is updated just 
because of the switch. However, the code is in svn (Tools/TestResultServer), so 
you are encouraged to update the list a appropriate.

- Alexey



30 июля 2015 г., в 5:29, Carlos Alberto Lopez Perez  
написал(а):

> On 30/07/15 09:10, Aakash Jain wrote:
>> Hi All,
>> 
>> We are planning to switch to new servers for two of the apps:
>> EWS(webkit-queues.appspot.com) and flakiness dashboard
>> 
> (http://webkit-test-results.appspot.com/dashboard/flakiness_dashboard.html).
> 
> 
> Regarding the flakiness dashboard it has been without updating the list
> of available bots for a lng time.
> 
> In fact, I always recommend to run it locally to get results from the
> bots added in the last year(s):
> 
> "The Flakiness Dashboard that is online
> (webkit-test-results.appspot.com) is very outdated regarding the list of
> bots. You will do better by running the flakiness dashboard locally. To
> do that just open with a browser the file
> Tools/TestResultServer/static-dashboards/flakiness_dashboard.html (it
> may take a bit to load even if run locally because it fetches the json
> files with the data from webkit.org). " [1]
> 
> 
> I hope that with this switch to new servers the flakiness dashboard will
> be also updated more frequently.
> 
> 
>> It would be good to restart all the bots communicating with these
>> apps to ensure that they switch to new server. We will be handling
>> most of the bots, except the ones which we don't have the admin
>> access to (e.g.: efl-wk2-ews and gtk-wk2-ews). It would be great if
>> the admins for these bots can do the necessary.
> 
> I will take care of switching the GTK EWS bots as soon as the patch lands.
> 
> Regards.
> 
> 
> 
> [1] https://trac.webkit.org/wiki/WebKitGTK/Gardening/Howto
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

[Alexey Proskuryakov]

24 апр. 2015 г., в 9:06, Brady Eidson  написал(а):

> Killing the feature would lead to a confusing experience for such users.

Additionally, I think that outright killing multipart main resources would 
cause unnecessarily confusing experience for WebKit developers. One of the 
first things we do when a resource is not displayed correctly is open it in in 
a new window.

It definitely seems appropriate to limit what we claim to support, making the 
main resource code path more like the subresource one, and removing code 
complexity along the way.

Anyway, the evidence of someone on the WebKit team being affected by this as a 
user seems like a fairly strong argument in this case.

- Alexey
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Running new/modified tests on EWS bots

[Alexey Proskuryakov]

19 марта 2015 г., в 8:46, youenn fablet  написал(а):

> Hi,
> 
> Related to the webkit contributor meeting discussion related to ports,
> I would find it useful if EWS bots (gtk, efl, win, ios) were running
> the tests that are modified/created by a patch.
> 
> The idea would be to turn yellow the port bubble whenever one of these
> tests do not pass. Results would be uploaded to bugzilla.
> 
> This would give an incentive for patch developers to try fixing the
> tests on these ports.
> That may reduce (slightly? noticeably?) port maintainers gardening effort.
> That would also be valuable when importing test suites.
> 
> Any potential issue? objection to move that forward?
> Anyone willing to help? Thoughts?

I think that it's a good idea. The infrastructure added for this could be 
reused for something that we wanted for a long time - on the Mac, we should run 
newly added tests multiple times and also with GuardMalloc enabled, to reduce 
the chances of them being flaky, or uncovering memory corruption. That's a low 
cost in terms of EWS performance.

- Alexey


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Running W3C tests using wptserve

[Alexey Proskuryakov]

This issue occurs on Mac bots. Windows EWS does not run regression tests, so it 
would not be affected.

Here is the log output:

WARNING:web-platform-test-launcher:/Volumes/Data/EWS/WebKit/LayoutTests/imported/w3c/web-platform-tests/tools/pywebsocket/src/test/__init__.py
 is not present, creating it as empty file
Traceback (most recent call last):
  File 
"/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/servers/web_platform_test_launcher.py",
 line 21, in 
create_wpt_empty_file_if_needed(['tools', 'pywebsocket', 'src', 'test', 
'__init__.py'])
  File 
"/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/servers/web_platform_test_launcher.py",
 line 17, in create_wpt_empty_file_if_needed
open(file_path, 'a').close()
IOError: [Errno 2] No such file or directory: 
'/Volumes/Data/EWS/WebKit/LayoutTests/imported/w3c/web-platform-tests/tools/pywebsocket/src/test/__init__.py'

Looks like the directory 
/Volumes/Data/EWS/WebKit/LayoutTests/imported/w3c/web-platform-tests/tools/pywebsocket/src/test
 does not exist.

- Alexey

> 1 февр. 2015 г., в 0:27, youenn fablet  написал(а):
> 
> Looking at the log, the dependencies seem to be installed correctly.
> Is it possible to get access to the corresponding
> WebKitBuild/Release/layout-test-results, in particular
> wptwk_process_log.out.txt?
> 
> Also, does it happen on all bots or only windows bot?
> 
> 
> 2015-02-01 4:41 GMT+01:00 Alexey Proskuryakov :
>> 
>>> 31 янв. 2015 г., в 11:57, youenn fablet  написал(а):
>>> 
>>> Currently, only two tests are run within that folder:
>>> - web-platform-tests/domparsing/DOMParser-parseFromString-html.html
>>> - web-platform-tests/domparsing/insert-adjacent.html
>>> 
>>> Should there be any issus with those tests, the problem may be related
>>> to running wptserve.
>> 
>> I see that these tests fail on EWS, any suggestions for how to debug the 
>> issue? The EWS setup is not much different from regular bots - the biggest 
>> difference is that EWS machines have more cores.
>> 
>> https://webkit-queues.appspot.com/results/6309998137180160
>> 
>> - Alexey
>> 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Running W3C tests using wptserve

[Alexey Proskuryakov]

> 31 янв. 2015 г., в 11:57, youenn fablet  написал(а):
> 
> Currently, only two tests are run within that folder:
> - web-platform-tests/domparsing/DOMParser-parseFromString-html.html
> - web-platform-tests/domparsing/insert-adjacent.html
> 
> Should there be any issus with those tests, the problem may be related
> to running wptserve.

I see that these tests fail on EWS, any suggestions for how to debug the issue? 
The EWS setup is not much different from regular bots - the biggest difference 
is that EWS machines have more cores.

https://webkit-queues.appspot.com/results/6309998137180160

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] run-webkit-tests question; hashes when comparing ref test output

[Alexey Proskuryakov]

23 янв. 2015 г., в 10:01, Ryosuke Niwa  написал(а):

> We could add a new test expectation like ImageDiff to suppress these or we 
> could expose a new internals or testRunner methods to mark a test as such.

Good idea! An ImageHashMismatch expectation seems like a reasonable way to 
silence the noise.

Also, I am surprised that we weren't getting a specific message about size 
mismatch here, as Darin suggested. In fact, we used to have this very output on 
other tests until very recently (see 
).

- Alexey

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev