<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Feb 6, 2017 at 7:32 PM Ryosuke Niwa &lt;<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Feb 6, 2017 at 4:22 PM, youenn fablet <span dir="ltr" class="gmail_msg">&lt;<a href="mailto:youennf@gmail.com" class="gmail_msg" target="_blank">youennf@gmail.com</a>&gt;</span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">It seems we agree in moving this forward. Any objection?</div><div class="gmail_msg">If so, let&#39;s start with small practical steps, something like a script to automatically generate WPT PR requests from a WebKit repo.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I think we need to first agree on where to put new tests. If we&#39;re placing next to existing tests inside LayoutTests/imported/w3c/web-platform-tests/ then identifying those new tests will be an issue.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Also, there needs to be a mechanism to detect these new tests that have been merged into upstream when we&#39;re re-importing. It&#39;s possible for tests newly added in WebKit to be renamed, moved, or otherwise modified before we re-import them back.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">All these situations need to be carefully thought out first.</div></div></div></div></blockquote><div><br></div><div>If it might be of any use, here&#39;s a doc where we hash out a lot of question for 2-way sync in Chromium:</div><div><a href="https://docs.google.com/document/d/1JgPTyIWmjlXyhyatiZ9A6fSbUQPjCyM26budEY90VDE/edit?usp=sharing">https://docs.google.com/document/d/1JgPTyIWmjlXyhyatiZ9A6fSbUQPjCyM26budEY90VDE/edit?usp=sharing</a><br></div><div><br></div><div>Linked from that is also an older doc with a lot of discussion:</div><div><a href="https://docs.google.com/document/d/1JOcZsURB3ITsRtundqkpVVDrqo6x-_jdif7s_0rLJD0/edit?usp=sharing">https://docs.google.com/document/d/1JOcZsURB3ITsRtundqkpVVDrqo6x-_jdif7s_0rLJD0/edit?usp=sharing</a><br></div><div><br></div><div>When it comes to identifying which commits to export next, we look for the most recent exported commit in web-platform-tests, map that to a Chromium commit, and then inspect all later commits that touch LayoutTests/external/wpt/. This scheme only works if commits are always exported in order. Note also that commits before the most recent import can also be candidates, because of imports racing with test changes in CQ. Automatic imports are also blocked on all exports being finished, to not (temporarily) revert changes.</div><div><br></div><div>Happy to provide more details on design and trade-offs if useful to you. Regardless, I&#39;m quite excited to see this happening in WebKit.<br></div></div></div>