Revert "Remove duplicated fonts and put them under /fonts/ (#9718)"

[mrego]

This reverts commit e45d0cf as it broke CSS test infrastructure.

[Ms2ger]

I suggest those interested in maintaining the CSSWG test infrastructure fix that instead.

[frivoal]

I suggest those interested in maintaining the CSSWG test infrastructure fix that instead.

This is not OK. The CSSWG test infrastructure may be quirky / not to your taste, but it works, and we're sharing this repo. Breaking it and letting other people deal with the fallout is not OK.

Reverting a single commit is much cheaper than requiring people to rewrite software that has worked for years.

Maybe we should replace the CSSWG test infrastructure. Maybe we should modernize it. But we haven't done that yet, so for now, we need this commit reverted.

CC: @plinss @gsnedders @fantasai

[plinss]

At this point I've added an alias to serve the wpt fonts directory from the root of test.csswg.org (in the same manner as we serve /resources), so this revert isn't necessary to get the built test suites and test harness working again.

This may be a reasonable long-term fix for this particular issue, but it needs some more consideration. We also need a better path forward for coordinating and testing these kinds of changes in the future.

[mrego]

Ok, let's close this then.

I'm sorry for breaking this, but I don't know what's the way to test it properly and know that you are not going to break anything.
Is there any way to do that in order to avoid this kind of issues in the future?

[foolip]

Reverting when things are broken by accident is pretty much the default, see these in the past 6 months:

• Revert "Fix #7142: Change manifest update process" #9737
• Revert "Switch external_host to host_ip. (#9258)" #9650
• Revert "auto-install Ahem font with flag (#7227)" #7307

I don't know exactly how the CSS build system is used, by given how fast @plinss noticed it sure seems like it's an important part of the workflow. Even though it touches lots of files, I believe this revert should have been done ASAP. It's already been imported into Blink with no trouble, but large changes tend to be more trouble, so spreading them out over time is no fun.

@plinss, is this revert still required to get everything back into shape? I would like to merge the revert, and @jgraham said on IRC "I don't mind reverting this", so I think that's what we should do.

We should revert this ASAP if still required to unblock the CSSWG, then work out how to reland.

[foolip]

Travis is failing, but there's no chance that Travis could pass, so we should ignore that too if we merge this. @plinss, will revert if I don't hear back before the end of day.

[mrego]

@foolip check the last comment from @plinss

At this point I've added an alias to serve the wpt fonts directory from the root of test.csswg.org (in the same manner as we serve /resources), so this revert isn't necessary to get the built test suites and test harness working again.

If I get it right this revert is no longer needed, so we can close this PR. Do you agree?

BTW, I also said I didn't have problems with the revert and I'm sorry for creating all this mess.

[plinss]

As far as I’m aware the current work-around is working, so no need to revert.

[foolip]

@mrego, yep, I saw it, but the "needs some more consideration" made we wonder if it's a speculative fix and not confirmed to be enough.

So, crisis averted, closing this, and just filed #9953 for "better path forward for coordinating and testing these kinds of changes in the future."

[plinss]

@foolip, as far as I know the current fix is enough to get things working again. The "needs some more consideration" just means I need to think if this is the best way to keep things working long-term (and maybe we need a generic system for paths to common files so we don't have to add these kinds of aliases over and over).

[gsnedders]

@plinss I think we should probably just make it possible to use all the top-level shared resource directories (common, fonts, images, media, resources); I think all of these have existed since WPT has, so there's not much risk of new ones getting added.

[plinss]

If it's just that set of 5 then fine, I can add the others as aliases to the csswg test server. All I had in mind was something like if new shared-resource directories get added that happens under /common (or let's create /shared and put everything, or all new things under that). That way new ones can be added without having to coordinate changes or worry about breakage.

[gsnedders]

@plinss given the most recent of them dates from 2013 in the repo, and web-platform-tests only really happened in 2014, I'd say the risk of adding any more is super low. :)

[foolip]

@gsnedders would a lint that checks that css/ only includes from those 5 top-level directories be expensive, you think?

[gsnedders]

@foolip it would add a lot of extra complexity versus what we have now (we'd have to extract URLs to check, which especially in css/ would mean finding some CSS parser to do so), and obviously it couldn't be complete (finding out what URLs JS might load obviously reduces to the halting problem).

[foolip]

@gsnedders, so there's nothing currently that checks anything about the included resources? Or just for scripts to catch broken testharness.js includes?

[foolip]

I realize that doing it for fonts would be quite challenging, we'd need a CSS parser for that.

[gsnedders]

@foolip We literally just do <script> and check that if it contains testharness.js it's the path we expect, and <link rel=match> has an href that points to something that exists. I think historically the majority of broken URLs in the built output of the CSS testsuite have been in CSS and not HTML, because that's where resources are mostly loaded (given they almost all use inline stylesheets).

[plinss]

The css build system also scans the entire wpt repo for tests that link to css specs, not just the /css directory, so a lint restricted to that directory wouldn't help

[foolip]

OK, I suppose a lint for this isn't really practical at this point.