Once CSS reftests land in wpt upstream we need to import them into m-c as part of the normal import process. This is expected to cause ~30,000 additional files to be added, so will need to be checked for perf. consequences.

There's also the duplication that we'll have from <layout/reftests/w3c-css/submitted>, which is currently one-way synced to csswg-test.

Given as far as I'm aware the script to sync <layout/reftests/w3c-css/submitted> to csswg-test <vendor-import/mozilla> are currently tied to Mercurial, it seems like on the face of it there isn't any point in rewriting the script and having a second syncing system for wpt. If that's the case, I presume we can then move the tests out of vendor-import and into their respective spec directories?

When I looked at the WPT files in the Servo repo, I saw that there were a number of very small files defining what are essentially per-test settings. Given that there is a non-trivial cost to a file in the checkout (slows down several version control operations both locally and in automation), would there be a way to consolidate these settings files so there were fewer files? Is that even a problem for these CSS reftests? FWIW, I last brain dumped about the consequence of excessive files in version control in bug 977849 comment 29 and below. As a person tasked with scaling version control at Mozilla, I'm committed to supporting whatever developers say we need to do, which includes running a monorepo for Firefox. I just want to encourage a reasonable amount of due diligence so we avoid unwanted strain on version control.

So I'm very uncomfortable with this, given my concerns about the way we run wpt reftests (multiple bugs filed, probably not complete) and my opinion that we should stop using a separate harness for them. The existing tests we have in w3c-css/submitted/ definitely need to continue to be run with our own reftest harness given that we'd otherwise lose substantial test coverage.