Utilities for updating BCD based on test results

[foolip]

This is a continuation of #6585, with a concrete proposal.

Background: https://github.com/foolip/mdn-bcd-collector generates tests, runs them, puts results in a special JSON format, and then updates BCD based on the results from many browser releases.

Updating BCD is done in the update-bcd script. This is in itself a surprisingly difficult problem, and the script doesn't deal with all edge cases, such as when test results indicate that a feature was added, removed, and then added back again. See foolip/mdn-bcd-collector#571 for more such cases. Additionally, this code needs to stay in sync with any changes to schema or relevant guidelines in BCD.

Proposal: To improve the quality and maintainability of this aspect, define a schema for test results, and add scripts to BCD itself for updating BCD based on test results. In other words:

• A JSON schema in BCD for test results for a single BCD browser release. It would be essentially a list of claims like "api.Element.setHTML is not supported in Chrome 99" or "css.properties.line-clamp (with webkit prefix) is supported in Safari 12".
• mdn-bcd-collector or similar tools produce JSON files matching that schema
• The update-bcd script is moved to BCD, and further improvements made in this repo

@Elchi3 @queengooborg WDYT?

[foolip]

One small detail I think will be important in practice is to only allow one claim per BCD entry. If we have some contradictory test results for a BCD entry, it should be the responsibility of the test infra to collapse that into a single result. This is currently done in update-bcd, but the correct choice depends on what the different tests were. Explicit support for partial_implementation claims would make sense I think.

[gsnedders]

One small detail I think will be important in practice is to only allow one claim per BCD entry. If we have some contradictory test results for a BCD entry, it should be the responsibility of the test infra to collapse that into a single result. This is currently done in update-bcd, but the correct choice depends on what the different tests were. Explicit support for partial_implementation claims would make sense I think.

I'm not sure that's workable in practice: that works if the results come from a single test run, but isn't necessarily going to be true if you're combining multiple JSON files from different runs.

A clear example here would be something like WebGL, where some of the extensions rely on hardware support, hence getting different test results for the same item for the same browser is pretty likely, and it would be nice for the script to be able to handle this in some meaningful way.

[foolip]

cc @jugglinmike @lolaodelola

[queengooborg]

Closing this issue since the decision was to keep the script inside of the collector instead of moving it to BCD.