RTCRtpTransceiver wpt has been quietly disabled
Categories
(Core :: WebRTC: Signaling, enhancement, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: bwc, Assigned: bwc)
References
Details
Attachments
(2 files)
It sure would be great if someone would let me know before they disable one of my tests...
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
When I try to re-enable our tests, I trip over bug 1522773.
Assignee | ||
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•6 years ago
|
||
Assignee | ||
Comment 4•6 years ago
|
||
Assignee | ||
Comment 5•6 years ago
|
||
Assignee | ||
Comment 6•6 years ago
|
||
Assignee | ||
Comment 7•6 years ago
|
||
Assignee | ||
Comment 8•6 years ago
|
||
Assignee | ||
Comment 9•6 years ago
|
||
Assignee | ||
Comment 10•6 years ago
|
||
Assignee | ||
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
I'm assuming the webkit patch in bug 1514432 busted this test for us and made it quietly disabled on the following metadata sync. James, can problems like this be mitigated somehow? Like automatic filing of a bug when a WPT-sync makes our support for a WPT-test worse?
Comment 13•6 years ago
|
||
The intent is that there is always a bug when something is disabled. In this case a harness change caused a bunch of new instability, blocking all wpt imports. In the scramble to fix that some bugs that ought to have been filed weren't.
So this situation already isn't supposed to happen, and I'm also working on tooling to give people better insights into the status of web-platform-tests in general so it will be even harder for something like this to happen again without people becoming aware.
Assignee | ||
Comment 14•6 years ago
|
||
Assignee | ||
Comment 15•6 years ago
•
|
||
(In reply to Andreas Pehrson [:pehrsons] from comment #12)
I'm assuming the webkit patch in bug 1514432 busted this test for us and made it quietly disabled on the following metadata sync. James, can problems like this be mitigated somehow? Like automatic filing of a bug when a WPT-sync makes our support for a WPT-test worse?
This was one of the problems, but there are much worse things that broke. I am trying to fix/compensate for them here.
Assignee | ||
Comment 16•6 years ago
|
||
Assignee | ||
Comment 17•6 years ago
|
||
Assignee | ||
Comment 18•6 years ago
|
||
I wonder why so many try pushes aren't running CI...
https://treeherder.mozilla.org/#/jobs?repo=try&revision=232543cb549957855126d6d152362d9ff11c83b9
Assignee | ||
Comment 19•6 years ago
|
||
Assignee | ||
Comment 20•6 years ago
|
||
Assignee | ||
Comment 21•6 years ago
|
||
Assignee | ||
Comment 22•6 years ago
|
||
Updated•6 years ago
|
Assignee | ||
Comment 23•6 years ago
|
||
Depends on D19548
Assignee | ||
Comment 24•6 years ago
|
||
Comment 25•6 years ago
|
||
Comment 26•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/1318991460b3
https://hg.mozilla.org/mozilla-central/rev/804dc60558df
Comment 29•6 years ago
|
||
This didn't merge upstream for failures in Firefox stability checking. I can force-merge the changes if you like, but it seems like there are still real issues to figure out with this test.
Description
•