Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
I filed https://bugs.webkit.org/show_bug.cgi?id=172068 to track the need for some extra tooling for HTTP/WPT served tests. We already gathered information about related requirements & workflows here. Let's add more there! Le ven. 12 mai 2017 à 19:50, a écrit : > > 12 мая 2017

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Anne van Kesteren
On Fri, May 12, 2017 at 11:49 PM, Maciej Stachowiak wrote: > It seems like there's two unusual things about WPT: > - At least according to Alexey, WPT tests are somewhat prone to flakiness in > Safari. Although they haven't always been working perfectly, changes to

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Brian Burg
> On May 12, 2017, at 7:31 PM, Alexey Proskuryakov wrote: > >> >> 12 мая 2017 г., в 16:12, Sam Weinig > > написал(а): >> >> >> >>> On May 12, 2017, at 2:49 PM, Alexey Proskuryakov >> >

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread ap
> 12 мая 2017 г., в 19:38, Brian Burg написал(а): > >> 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 >>

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Ryosuke Niwa
On Fri, May 12, 2017 at 7:38 PM, Brian Burg wrote: > > If the person works on WebKit, then it seems unreasonable that they would do > work without a checkout. This is not entirely true. If I have an iOS device, it's a lot easier to load up a web page on a public server

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Ryosuke Niwa
On Fri, May 12, 2017 at 7:31 PM, Alexey Proskuryakov wrote: > > 12 мая 2017 г., в 16:12, Sam Weinig написал(а): > > > > On May 12, 2017, at 2:49 PM, Alexey Proskuryakov wrote: > > > 12 мая 2017 г., в 14:38, Sam Weinig

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Alexey Proskuryakov
> 12 мая 2017 г., в 16:12, Sam Weinig написал(а): > > > >> On May 12, 2017, at 2:49 PM, Alexey Proskuryakov > > wrote: >> >> >>> 12 мая 2017 г., в 14:38, Sam Weinig >> > написал(а): >>>

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
> On the topic of LayoutTest/imported tests, can someone describe the > current process of working with LayoutTest/imported? > > How do we handle a broken test in our tree? > > • Do we modify our expectations? > > - If so, how do we remember to change the expectations in a later import? > > If a

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Joseph Pecoraro
> On May 12, 2017, at 2:39 PM, Ryosuke Niwa wrote: > > On Fri, May 12, 2017 at 12:04 PM, Alexey Proskuryakov > wrote: > >> We don't have a concept of "first class", but I hope that when choosing >> between looking into a simple test

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Sam Weinig
> On May 12, 2017, at 2:49 PM, Alexey Proskuryakov wrote: > > >> 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

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
I would guess Chromium and Mozilla to have the same issues there. Incidentally, some work is being done right now to ease the run-a-server-then-launch-a-browser thing. We should be able to piggy-back on that effort and also handle the same thing for LayoutTetsts/http/tests.

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread 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

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Maciej Stachowiak
> On May 12, 2017, at 2:39 PM, Ryosuke Niwa wrote: > > On Fri, May 12, 2017 at 12:04 PM, Alexey Proskuryakov wrote: >> >> 12 мая 2017 г., в 11:52, Ben Kelly написал(а): >> >> On Fri, May 12, 2017 at 2:26 PM, Rick Byers

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread 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 >

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Brian Burg
> On May 12, 2017, at 2:10 PM, Simon Fraser wrote: > >> >> On May 12, 2017, at 12:04 PM, Alexey Proskuryakov > > wrote: >> >> >>> 12 мая 2017 г., в 11:52, Ben Kelly >> >

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Sam Weinig
> On May 12, 2017, at 2:10 PM, Simon Fraser wrote: > > >> On May 12, 2017, at 12:04 PM, Alexey Proskuryakov > > wrote: >> >> >>> 12 мая 2017 г., в 11:52, Ben Kelly >> >

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Ryosuke Niwa
On Fri, May 12, 2017 at 2:10 PM, Simon Fraser wrote: > > On May 12, 2017, at 12:04 PM, Alexey Proskuryakov wrote: > > > 12 мая 2017 г., в 11:52, Ben Kelly написал(а): > > On Fri, May 12, 2017 at 2:26 PM, Rick Byers

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Chris Dumez
Our test importer script is perfectly able to rewrite those paths to use relative paths. However, Youenn, who imports and re-syncs most tests does not like this option I believe. I think, part of the issue is that *some* tests do not do the right thing when loading over file:// (e.g. security

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Christian Biesinger
For what it's worth, my personal solution to this was to put a symlink in / for the resources directory: lrwxrwxrwx 1 root root 55 Dec 11 2015 /resources -> /home/cbiesinger/csswg-test/resources/ Hm, I guess I should update that to web-platform-tests now! Christian On Fri, May 12, 2017 at

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Simon Fraser
> On May 12, 2017, at 12:04 PM, Alexey Proskuryakov wrote: > > >> 12 мая 2017 г., в 11:52, Ben Kelly > > написал(а): >> >> On Fri, May 12, 2017 at 2:26 PM, Rick Byers > >

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
Filed https://github.com/w3c/web-platform-tests/issues/5909 and https://github.com/w3c/web-platform-tests/issues/5910. Le ven. 12 mai 2017 à 12:08, Rick Byers a écrit : > On Fri, May 12, 2017 at 2:43 PM, youenn fablet wrote: > >> >> Le ven. 12 mai 2017

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Rick Byers
On Fri, May 12, 2017 at 2:43 PM, youenn fablet wrote: > > Le ven. 12 mai 2017 à 11:07, Alexey Proskuryakov a écrit : > >> >> 9 мая 2017 г., в 11:27, Simon Fraser написал(а): >> >> >> Another consideration here is "would my test be

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Alexey Proskuryakov
> 12 мая 2017 г., в 11:52, Ben Kelly написал(а): > > On Fri, May 12, 2017 at 2:26 PM, Rick Byers > wrote: > On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov > wrote: > Since

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Ben Kelly
On Fri, May 12, 2017 at 2:26 PM, Rick Byers wrote: > On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov > wrote: > >> Since imported WPT tests are very flaky, and are not necessarily written >> to defend against important regressions, investigating issues

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread youenn fablet
Le ven. 12 mai 2017 à 11:07, Alexey Proskuryakov a écrit : > > 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

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Rick Byers
On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov wrote: > > 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

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread 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.

Re: [webkit-dev] Fwd: Port WebKit to GNUstep

2017-05-12 Thread Konstantin Tokarev
12.05.2017, 18:14, "Daniel Ferreira (theiostream)" : > On Fri, May 12, 2017 at 11:17 AM, Konstantin Tokarev > wrote: >>  Choice of the correct MemoryPressureHandler implementation can be done >>  in your Platform*.cmake >> >>  Note that you don't need to

Re: [webkit-dev] Fwd: Port WebKit to GNUstep

2017-05-12 Thread Daniel Ferreira (theiostream)
On Fri, May 12, 2017 at 11:17 AM, Konstantin Tokarev wrote: > Choice of the correct MemoryPressureHandler implementation can be done > in your Platform*.cmake > > Note that you don't need to duplicate PlatformMac files and make changes, > it would be wiser to

Re: [webkit-dev] Fwd: Port WebKit to GNUstep

2017-05-12 Thread Konstantin Tokarev
12.05.2017, 17:03, "Daniel Ferreira (theiostream)" : > On Thu, May 11, 2017 at 11:58 PM, Ryosuke Niwa wrote: >>  Are you intending to maintain this port going forward? The bar for >>  introducing a new port in the WebKit repository is pretty high due to >>  

Re: [webkit-dev] Fwd: Port WebKit to GNUstep

2017-05-12 Thread Daniel Ferreira (theiostream)
On Thu, May 11, 2017 at 11:58 PM, Ryosuke Niwa wrote: > Are you intending to maintain this port going forward? The bar for > introducing a new port in the WebKit repository is pretty high due to > the maintenance cost it incurs to all other contributors. Unless > you're

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Ryosuke Niwa
On Thu, May 11, 2017 at 11:32 PM, Anne van Kesteren wrote: > On Fri, May 12, 2017 at 6:46 AM, Simon Fraser wrote: >> I was under the impression that tests upstreamed from vendor repositories >> would land in WPT tests >> with minimal review, based on

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Anne van Kesteren
On Fri, May 12, 2017 at 6:46 AM, Simon Fraser wrote: > I was under the impression that tests upstreamed from vendor repositories > would land in WPT tests > with minimal review, based on the fact that they had been reviewed when > landed in the vendor repo. I think