Closed Bug 989448 (compat-data) Opened 9 years ago Closed 5 years ago

Compatibility Data tracking bug

Categories

(developer.mozilla.org Graveyard :: BrowserCompat, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: Jeremie, Unassigned)

References

()

Details

(Keywords: meta, Whiteboard: [bc:infra][bc:front][bc:kuma][bc:mdn][bc:milestone=tardis])

This is the tracking bug for the compatibility data project.
Technical Kick-off meetings has been done, here's the note: https://etherpad.mozilla.org/cdp-tech-kick-off-2014-03-28
Severity: normal → enhancement
Depends on: 996570
Depends on: 946413
Alias: compat-data
Depends on: 1006002
Depends on: 1006010
Depends on: compat-mdn-tables
Depends on: 1006030
Depends on: 1006042
Technical Kick-off meetings has been done, here's the note:
https://etherpad.mozilla.org/cd-ux-kick-off
Depends on: 1006534
Depends on: 1006539
Blocks: 1006534
No longer depends on: 1006534
Depends on: 1017060
Depends on: 1050458
Depends on: 1059577
I have some information that you might find useful. I think there's potential room for interesting collaboration in here.

As you may or may not know, a bunch of us have been working on a project called "Web Platform Tests" (https://github.com/w3c/web-platform-tests/). The goal is to have a single one-stop shop for the testing of all (standardised) Web technologies. We're not completely there yet (notably CSS, JS, and WebGL are tested elsewhere) but we nevertheless have a lot of tests, that have gone through quality review, for HTML, the DOM, and a bunch of other APIs and things.

James Graham has been developing a tool (wptrunner) that can automatically run all of those tests (or nearly all) against a browser engine. I know he's integrated that with Servo and it is now running as part of the Gecko CI tests.

One thing that is cool with wptrunner is that it uses WebDriver. Another thing that uses WebDriver is SauceLabs (where we have an account). Putting these two things together means that we ought to be getting raw result data for a lot of tests on a *lot* of browsers and device configurations.

Parallel to this, there is ongoing work to vastly improve the links between individual test results, what they are testing in specifications, and "features" (the granularity that usually makes sense when developing). We have part of the infrastructure for this, but it's probably at least a few months away. We could certainly use your input about what type of granularity would make sense here. (We're also digging around for funds to make the guy working on this join us face to face for some high-bandwidth hacking later this year — if you have suggestions for that we'd love to hear.)

All in all I reckon that the data we produce with this could be very useful for this project. We'd certainly like to hear your ideas about how we could make the data more useful to you, the idea being that we want it to be very reusable by third-parties.
That sounds really promising. :hoosteeno - want to follow up with this?
Flags: needinfo?(hoosteeno)
(In reply to Robin Berjon from comment #3)
> As you may or may not know, a bunch of us have been working on a project
> called "Web Platform Tests" (https://github.com/w3c/web-platform-tests/).

Yup, I'm aware of this :)
We listed this as one of the tests suit we are considering to fill our data base
https://wiki.mozilla.org/MDN/Projects/Development/CompatibilityTables#tests_suite

> James Graham has been developing a tool (wptrunner) that can automatically
> run all of those tests (or nearly all) against a browser engine. I know he's
> integrated that with Servo and it is now running as part of the Gecko CI
> tests.

That's great, as it means that we should be able to use it quite easily to get raw Firefox compatibility information

> One thing that is cool with wptrunner is that it uses WebDriver. Another
> thing that uses WebDriver is SauceLabs (where we have an account).

Oh! I wasn't aware of that, Selenium FTW \o/

> Parallel to this, there is ongoing work to vastly improve the links between
> individual test results, what they are testing in specifications, and
> "features" (the granularity that usually makes sense when developing). We
> have part of the infrastructure for this, but it's probably at least a few
> months away. We could certainly use your input about what type of
> granularity would make sense here. (We're also digging around for funds to
> make the guy working on this join us face to face for some high-bandwidth
> hacking later this year — if you have suggestions for that we'd love to
> hear.)

As first though, I suggest you or W3C people involved in this project take a look at:
https://wiki.mozilla.org/MDN/Development/CompatibilityTables/Data_Requirements

Then, as :groovecoder suggest it, :hoosteeno could follow up with this (Justin, tell me if you need some help on this)

> All in all I reckon that the data we produce with this could be very useful
> for this project. We'd certainly like to hear your ideas about how we could
> make the data more useful to you, the idea being that we want it to be very
> reusable by third-parties.

:groovecoder and John Whitlock are working on the API to access our data base, I guess that I some point it will be interesting to get feedback from James Graham about it.
(In reply to Luke Crouch [:groovecoder] from comment #4)
> That sounds really promising. :hoosteeno - want to follow up with this?

Yes! I'll reach out to Jeremie & Robin for a chat.
Flags: needinfo?(hoosteeno)
Duplicate of this bug: 933851
Component: General → BrowserCompat
Whiteboard: [bc:infra][bc:front][bc:kuma][bc:mdn]
Depends on: 1242437
Depends on: 1242444
Whiteboard: [bc:infra][bc:front][bc:kuma][bc:mdn] → [bc:infra][bc:front][bc:kuma][bc:mdn][bc:milestone=tardis]
No longer blocks: 1006534
No longer depends on: 1050399
The BrowserCompat project is cancelled.  See https://github.com/mdn/browser-compat-data for the current effort.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.