foolip, smcgruer_[EST]: is there any plan for the backlog of github.com/web-platform-tests/wpt/p…t+merge+yet%22++label%3Ainterfaces?

gsnedders: not an immediate term plan. it's become pretty apparent that this model of sending PRs for each change individually, while it does avoid things getting blocked on unrelated issues, creates way too many PRs to deal with effectively. Now that npmjs.com/package/@webref/idl is a thing, my thinking is we should use that instead, and sync all IDL files at once. That package has fixes to ensure certain problems can't happen.

gsnedders: is there a specific spec's IDL you'd like to get updated?

foolip: no, was just noticing that nearly a fifth of open non-export PRs are infrastructure updates

s/infrastucture/interface/

gsnedders: yeah maybe I should first update the script to never add files, and close all of those, that would help, right?

foolip: that just sounds like a way to miss coverage of new IDL

gsnedders: That's what will happen, yes. right now others could review the "Add ..." PRs, but I don't know if anyone other than I or smcgruer_[EST] ever do.

foolip: btw, how long does it take to run mdn-results-collector against all browsers on BrowserStack? How practical is that to have as a GitHub Action upon release?

gsnedders: today is actually the first time I've even run the script, but Vinyl says it takes something like 45 minutes to run them all, so too long.

gsnedders: however I suspect this could be optimized, there's now really just a single page loaded to run the tests. and I suspect the way that worker tests are run is inefficient (a lot of eval and postMessage)

foolip: could shard by browser, then each chunk won't take too long, at least?

What does this do?

gsnedders: it's already running 5 in parallel, but yeah, it's possible one could get under the GitHub Actions limits by sharding. Although 5 is the parallelism limit on the BrowserStack account I use.

jgraham: this is about collect results from mdn-bcd-collector.appspot.com in very old browsers

foolip: yeah, I guess it's "can you do the Actions one after the other"

gsnedders: yeah, I guess the total time budget is something like 3 hours so it should be possible.

gsnedders: note that using old results with update-bcd.js works fine too, I'm still using the ones currently in mdn-bcd-results.

foolip: though using results from mixed sets can end up with plenty of "<=x"

foolip: and the quantity of that is where I started getting annoyed :)

gsnedders: yes, if there are versions missing you'll get those funny strings. if you use just two reports I think you may still get them, I'm not sure. the basic problem is that so much of the existing data is contradicted by test results, so with any set of results you'll generate lots and lots of changes.

gsnedders: `git diff -S` might help bring down the size of the diff. or we should add more options to update-bcd.js to make it more suitable for partial updates, not the "let's fix api.*" project this was created for

foolip: right, there are ways to workaround it, but still

gsnedders: I've filed foolip/mdn-bcd-collector #1000, do you think that's the right solution? Or is the important use case more like "here's data for a beta release, make sure everything in it will be updated"?