<div dir="ltr">Hi all,<div><br></div><div>After talking with some WebKittens, I'd like to discuss the process of upstreaming WPT tests from WebKit. Here is my take of it.</div><div><br></div><div>WPT tests need a review before being merged.</div><div>This review can be done in WPT GitHub at PR time.</div><div>This review can also be done as part of the usual WebKit review flow.</div><div><br></div><div>As done by other browser teams, a test that is reviewed in WebKit bugzilla and landed in WebKit can be readily merged into WPT without additional review (although additional review is always great!).</div><div>The only constraint I know of is that the test does not give flaky tests from WPT Chrome/Firefox bots.</div><div><br></div><div>We do not have yet the tooling to automate the creation of a WPT GitHub PR from a WebKit patch that lands.<br></div><div>In the meantime, for those of us planning to contribute to WPT, it might make sense to start using a consistent flow.<br></div><div>How about marking explicitly the PRs as coming from WebKit in the title, with the related bugzilla URL in the comment?</div><div><div>Patch at <a href="https://bugs.webkit.org/show_bug.cgi?id=169462">https://bugs.webkit.org/show_bug.cgi?id=169462</a> might be handy for that.<br></div><div>When done so, how about allowing any WebKitten with WPT repository merge access to merge those PRs without further review?</div><div><br></div></div><div><div>It might (and did) happen that a proposed test is conforming to the spec but the spec is expected to change at some point.</div><div>I don't think we should refrain from landing such test in WPT.</div><div>A test exercising the currently described behavior is a good thing anyway.</div><div>It might actually ease the job of those who will later need to provide a test that will cover the spec change.</div><div><br></div></div><div>Thanks</div><div>    y<br></div></div>