Do you both object just as much if ./mach puts the tests in tree via another mechanism than git clone of servo/servo? If we combined this with having our _mozilla tests in servo/servo until they are upstreamed, this would make contributing new tests just as easy as it is now and fix the repo integration issues, at the cost of making editing existing non-_mozilla tests slightly harder.
This may also make contributing to upstream and maintaining two-way sync easier as well. jack. On Thu, Aug 25, 2016 at 3:45 AM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 25/08/16 08:56, Ms2ger wrote: >> >> On 24/08/16 18:12, Lars Bergstrom wrote: >>> >>> Currently, the GitHub Servo repository has 134,062 files... 131,477 of >>> which are in the tests/ directory. Of those, 102,871 are in the CSS WG >>> tests. I know it's not a perfect measure, but that's also 862megs of >>> the 1.132gb of disk space usage reported by `du` on macOS for a Servo >>> checkout. >>> >>> So, I'd like to have a discussion to see if there's something we can >>> do here to reduce the number of files. There are two reasons this has >>> come up: >>> - If we do end up "copying" the Servo GitHub repository into the >>> Mozilla monorepo, unfortunately mercurial cannot scale to that number >>> of files (though there is work going on at Facebook to make it able to >>> do so in the next year or two). Plus, the non-CSS WG tests in the WPT >>> directory are duplicate with those already in m-c. >>> - That's a lot of disk space, and might not be needed for new >>> contributors who working on anything other than layout features. >>> >>> There are a few options I can see here (apart from "do nothing"): >>> 1) Reduce the duplication in the CSS WG tests. A lot of it is due to >>> the build system. How small could we get it? Similar to WPT (i.e., 10x >>> fewer files)? >>> 2) Break out the CSS WG and WPT tests into a separate location, to be >>> downloaded as-needed. If we do this, though, what is the workflow for >>> adding, deleting, or correcting a test? And is it still just as easy >>> to run a single test? Jamming it in a crate will leave it in a wonky >>> directory (e.g., target/debug/build/csswg-7062634bbf237306/output) >>> that is not exactly awesome for viewing & running tests from. >>> >>> Any opinions or other ideas here? >> >> >> I vehemently object to moving wpt out of tree; that would significantly >> discourage people from writing tests, especially tests that can be >> shared with other browsers. (Shared tests are the single best way of >> ensuring we are compatible with other browser engines, and they with us.) >> >> The csswg tests have a number of issues resulting from the way their >> build system works, but there's little point in spending resources >> there; the built copy of the tests will be removed in the coming months, >> as the unbuilt version will be added to wpt. (At that point: see the >> paragraph above.) > > > I agree with Ms2ger. Maybe I should just make that my sig :) I think it's > easy to focus on the cost of these files and neglect the immense value that > they bring. AIUI once the build system is gone it will be possible to > directly contribute css tests upstream like we do with any other kind of wpt > tests. > > As Simon estimates, without the build step, the number of files is reduced > by a factor of ~3. If that still isn't good enough it is possible to > consider hacks like never importing tests for specifications that servo > doesn't support yet, but those are intrinsically short-term gains. There may > also be some smaller, high-effort, but longer term gains from things like > merging (layoutwise) duplicate reference files. However if servo/servo > doesn't end up in m-c that seems like a lower-value proposition (especially > given that all of these files will be in m-c anyway). > > > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
