[webkit-dev] (no subject)

[Guido Trentalancia]

Hello everybody,

I have created some new webkit code changes to improve security and privacy by 
optionally disabling the CORS functionality:

https://bugs.webkit.org/show_bug.cgi?id=179886

Is there any way to speed up the review and approval process? 

Thanks, 

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

[Robert Ma]

On Fri, Nov 24, 2017 at 9:09 AM, Frédéric WANG  wrote:
> Right, running all the tests is nice. But sometimes I personally feel
> guilty to have to execute everything on EWS for example to retrieve
> results for macOS/iOS (when I did not have access to a mac) or to fix
> compilation failures on Windows ports. So better granularity would be
> helpful in my opinion. In any cases, this was just one idea and people
> working on CI and infrastructure are in better position to know how to
> improve running time of WPT tests. I'm surprised that I don't hear such
> complaints from Mozilla and Chromium (but maybe I'm not aware of them).

Chromium has build bots that are similar to EWS. Some bots run before every
patch lands (CQ bots), while the other bots can be requested to run any
time with a WIP patch (try bots). CQ bots run *all* layout tests + WPT,
among other tests, on all major platforms. Try bots are similar, but one
select a subset of bots (platforms) to run. This is made possible by the
infrastructure team with the fancy LUCI system, especially the distributed
test execution system Swarming

.

Running all layout tests + WPT on a single machine takes hours, so I don't
think Blink engineers often do that locally. Generally speaking, people
will use try bots liberally to test 'em all whenever they want to run more
than just a handful of tests.

That said, we can of course benefit from WPT performance improvement as
well.

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

[Frédéric WANG]

On 17/11/2017 17:23, Maciej Stachowiak wrote:
> I should also note that pulling in the test suite won't automatically
> get the bugs fixed or prioritized, or even filed in the bug tracker
> necessarily.eratwerATWeRTWAerATWertwAerer 
Sure. However, I believe in general having more people importing the WPT
tests and trying to match the behavior of the spec and of other browsers
would help, if only to be aware of issues (as Philip mentioned we could
also improve notifications etc). In the particular cases I mentioned
https://bugs.webkit.org/show_bug.cgi?id=162668 was reported one year ago
after Khaled Hosny (invited expert for the WebFonts WG) fixed the bug in
the GTK port while https://bugs.webkit.org/show_bug.cgi?id=179237 just
requires to backport the changes in Chromium to match the latest WebVTT
spec. These are of course only two examples, but in general more tests
shared with the rest of the Web Platform community (developers and spec
authors) are very useful for improving WebKit and interoperability.
> I find it super convenient that EWS runs all the tests even on WIP
> patches. It often catches test failures in tests I didn't think to run
> myself. I think it would be great if EWS could run tests on more
> platforms. Just running release regression tests on more platforms
> would be a big win, if debug builds are the gating factor. I guess it
> would be kind of neat to have a feature of "run the tests across all
> configurations, but only some of them". But I don't think I would
> prioritize it over having more kinds of tests, or finding ways to make
> the full test suite run faster.
Right, running all the tests is nice. But sometimes I personally feel
guilty to have to execute everything on EWS for example to retrieve
results for macOS/iOS (when I did not have access to a mac) or to fix
compilation failures on Windows ports. So better granularity would be
helpful in my opinion. In any cases, this was just one idea and people
working on CI and infrastructure are in better position to know how to
improve running time of WPT tests. I'm surprised that I don't hear such
complaints from Mozilla and Chromium (but maybe I'm not aware of them).

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
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

[Philip Jägenstedt]

On Fri, Nov 17, 2017 at 5:23 PM, Maciej Stachowiak  wrote:
>
>
>> On Nov 17, 2017, at 7:53 AM, Frédéric WANG  wrote:
>>
>> On 17/11/2017 16:26, Maciej Stachowiak wrote:
>>> WebKit has a lot of tests that were regression tests for a specific
>>> bug fix, not as conformance tests (though they might b useful for that
>>> too). In such cases, the association with the bugs.webkit.org bug is
>>> more important than the spec URL. That’s particularly the case when
>>> the test has been changed multiple times to reflect further WebKit
>>> behavior changes. I know that I’ve personally found it very useful to
>>> look at revision history of tests, or search for bug numbers or
>>> keywords in LayoutTests/ChangeLog to find related tests.
>>> Not saying this is the sole purpose of tests, but losing this ability
or making it more awkward would be a downside to deleting tests from the
WebKit repo.
>> Well, I think we agree here, that's why "conformance" tests was
>> specified in my message. For such tests, connecting the history of tests
>> with the development of the specs is actually more important. For
>> example I recently noticed that some bugs with WOFF2 (on Apple's ports
>> only) and WebVTT have been ignored in WebKit because we don't
>> import/sync WPT tests for these specs.
>
> I think importing new test suites is a different question than
upstreaming/removing tests. In general importing more test suites is
probably good, but we probably need to tackle the WPT performance problem
before we pull in too many new WPT suites.
>
> I should also note that pulling in the test suite won't automatically get
the bugs fixed or prioritized, or even filed in the bug tracker necessarily.

This is the case in Chromium as well, although Robert Ma is working on
import notifications:
https://docs.google.com/document/d/1W3V81l94slAC_rPcTKWXgv3YxRxtlSIAxi3yj6NsbBw/edit?usp=sharing

We don't know yet what's going to work well, but I think that somehow,
before too long, we need to at least triage all new failures. Far from all
will be worth prioritizing of course, but sometimes the existence of the
test can reduce the effort and make it easier to prioritize.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev