Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On 02/11/15 18:43, Josh Matthews wrote: https://github.com/servo/servo/wiki/Meeting-2015-11-02 For the record, I'm very against trying to run mochitests in Servo. As I understand it the additional features it offers over wpt are mostly because it leverages gecko-internal APIs that Servo doesn't support. To the extent that it's necessary to support similar test-only APIs for Servo, I don't think trying to make them bug-compatible with the Gecko implementations is a worthwhile goal; better just to implement the features that we need WebDriver or as servo-only DOM APIs and writing web-platform-tests, even if we can't share all of them. In the case we can share them, of course, that multiplies the value of the test enormously since we can also run it in Gecko, Blink, Edge, etc. The js API for writing interactive tests through WebDriver is a contributor project right now, and we also have preliminary interest from Google in collaborating on this effort so they can also write tests in this style, so I expect to see something usable in the near future. In terms of Servo work, this will require more WebDriver support to be implemented; I think a reasonable fraction of what's missing would be Good First Bug material. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
> 2016 Roadmap > https://docs.google.com/spreadsheets/d/1HYoEo5Vx9XuFWFh_1zGWtT-pvebNqspY-PqbUzh3y7Q/edit#gid=0 I seem this document is not public for users who does not have a 'at mozilla.org' account. Could you change the permission? 2015-11-03 3:43 GMT+09:00 Josh Matthews : > https://github.com/servo/servo/wiki/Meeting-2015-11-02 > > cheers, > Josh > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo -- Tetsuharu OHZEKI ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
I believe that's the internal spreadsheet, not supposed to be public. The roadmap on the wiki exists -Manish Goregaokar On Tue, Nov 3, 2015 at 4:10 PM, Tetsuharu OHZEKI wrote: > > 2016 Roadmap > > > https://docs.google.com/spreadsheets/d/1HYoEo5Vx9XuFWFh_1zGWtT-pvebNqspY-PqbUzh3y7Q/edit#gid=0 > > I seem this document is not public for users who does not have a 'at > mozilla.org' account. > Could you change the permission? > > > > 2015-11-03 3:43 GMT+09:00 Josh Matthews : > > https://github.com/servo/servo/wiki/Meeting-2015-11-02 > > > > cheers, > > Josh > > ___ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > > > -- > Tetsuharu OHZEKI > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
You can also see it here publicly: https://docs.google.com/spreadsheets/d/1HYoEo5Vx9XuFWFh_1zGWtT-pvebNqspY-PqbUzh3y7Q/pubhtml There's nothing private about it! I just gave up after a half an hour trying to figure out "how do I share this google doc so that everyone in Mozilla+a list of contributors can edit it, but the public can only view it," so I have the editable link for internal use and the "published" view for externals. I'll add that link to the meeting notes - thanks for catching it! - Lars On Tue, Nov 3, 2015 at 5:21 AM, Manish Goregaokar wrote: > I believe that's the internal spreadsheet, not supposed to be public. > > The roadmap on the wiki exists > > -Manish Goregaokar > > On Tue, Nov 3, 2015 at 4:10 PM, Tetsuharu OHZEKI > wrote: > >> > 2016 Roadmap >> > >> https://docs.google.com/spreadsheets/d/1HYoEo5Vx9XuFWFh_1zGWtT-pvebNqspY-PqbUzh3y7Q/edit#gid=0 >> >> I seem this document is not public for users who does not have a 'at >> mozilla.org' account. >> Could you change the permission? >> >> >> >> 2015-11-03 3:43 GMT+09:00 Josh Matthews : >> > https://github.com/servo/servo/wiki/Meeting-2015-11-02 >> > >> > cheers, >> > Josh >> > ___ >> > dev-servo mailing list >> > dev-servo@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-servo >> >> >> >> -- >> Tetsuharu OHZEKI >> ___ >> dev-servo mailing list >> dev-servo@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-servo >> > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On Tue, Nov 3, 2015 at 10:10 PM, James Graham wrote: > On 02/11/15 18:43, Josh Matthews wrote: > >> https://github.com/servo/servo/wiki/Meeting-2015-11-02 >> > > For the record, I'm very against trying to run mochitests in Servo. As I > understand it the additional features it offers over wpt are mostly because > it leverages gecko-internal APIs that Servo doesn't support. We have a ton of mochitests that either don't use special APIs at all, or do so only in very limited ways. There's a lot of value in those tests that I'd hate to just leave behind. Why not create a Mochitest compatibility layer over testharness.js so that tests that only use SimpleTest.waitForExplicitFinish(), SimpleTest.finish(), is(), todo() and ok() can run on Servo with trivial changes? Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
That sounds like a good idea. Perhaps we should do this on the mozilla-central side; move things out of mochitest into WPT? Is there an easy way of identifying browser-agnostic mochitests? -Manish Goregaokar ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On Wed, Nov 4, 2015 at 1:48 PM, Manish Goregaokar wrote: > That sounds like a good idea. Perhaps we should do this on the > mozilla-central side; move things out of mochitest into WPT? > > Is there an easy way of identifying browser-agnostic mochitests? > Maybe grepping for the obvious showstoppers (SpecialPowers, EventUtils.js) and just trying to run the rest... Regexp-based mass conversion might be reasonable too, with some human review. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
We probably can't do it in an automated way; tests being converted to WPT need to match spec and usually also need a spec link in the top. We could, however, import them wholesale into Servo's tests/wpt/mozilla/foo, and then manually pick through them. -Manish Goregaokar On Wed, Nov 4, 2015 at 6:25 AM, Robert O'Callahan wrote: > On Wed, Nov 4, 2015 at 1:48 PM, Manish Goregaokar > wrote: > >> That sounds like a good idea. Perhaps we should do this on the >> mozilla-central side; move things out of mochitest into WPT? >> >> Is there an easy way of identifying browser-agnostic mochitests? >> > > Maybe grepping for the obvious showstoppers (SpecialPowers, EventUtils.js) > and just trying to run the rest... > > Regexp-based mass conversion might be reasonable too, with some human > review. > > Rob > -- > lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf > toD > selthor stor edna siewaoeodm or v sstvr esBa kbvted,t > rdsme,aoreseoouoto > o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea > lurpr > .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr > esn > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On 03/11/15 22:08, Robert O'Callahan wrote: Why not create a Mochitest compatibility layer over testharness.js so that tests that only use SimpleTest.waitForExplicitFinish(), SimpleTest.finish(), is(), todo() and ok() can run on Servo with trivial changes? A few reasons I am skeptical of this: * Mochitests test gecko behaviour, not standardised behaviour. These can and do differ. Therefore they are even less trustworthy than the average test. * Mochitests are really written assuming the full gecko featureset. Given the total lack of isolation between asserts, they may behave rather unexpectedly and misleadingly in a browser not having all those features. * In the long term having multiple APIs for writing tests that people have to learn in order to read tests is a big net negative. If we allow mochitests to be upstreamed with a shim we should expect other vendors to do the same, and to end up with half a dozen possible test formats. In addition, I don't think that using mochitests which don't use internal APIs helps at all with the original problem of testing things like dynamic style changes that require internal-only APIs to trigger. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
> * In the long term having multiple APIs for writing tests that people have > to learn in order to read tests is a big net negative. If we allow > mochitests to be upstreamed with a shim we should expect other vendors to > do the same, and to end up with half a dozen possible test formats. > What if we translate instead of shimming? At least upstream all spec-conformant browser-agnostic tests. > > In addition, I don't think that using mochitests which don't use internal > APIs helps at all with the original problem of testing things like dynamic > style changes that require internal-only APIs to trigger. > Agreed, still need webdriver. Once we get webdriver it might be nice to translate&upstream even more content mochitests to WPT or wherever we'll be keeping the webdriver tests. -Manish Goregaokar ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On 04/11/15 04:52, Manish Goregaokar wrote: * In the long term having multiple APIs for writing tests that people have to learn in order to read tests is a big net negative. If we allow mochitests to be upstreamed with a shim we should expect other vendors to do the same, and to end up with half a dozen possible test formats. What if we translate instead of shimming? At least upstream all spec-conformant browser-agnostic tests. Well certainly, taking a mochitest, removing any gecko/spidermonkey specific assumptions or non-standard features, and rewriting it as a web-platform-test seems unarguably good. It also seems like it will be a non-trivial amount of work. Worth doing, but not exactly a source of free tests. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On Wed, Nov 4, 2015 at 5:14 PM, James Graham wrote: > On 03/11/15 22:08, Robert O'Callahan wrote: > > Why not create a Mochitest compatibility layer over testharness.js so >> that tests that only use SimpleTest.waitForExplicitFinish(), >> SimpleTest.finish(), is(), todo() and ok() can run on Servo with trivial >> changes? >> > > A few reasons I am skeptical of this: > > * Mochitests test gecko behaviour, not standardised behaviour. These can > and do differ. Therefore they are even less trustworthy than the average > test. > I'm not sure what you mean by this. It's easy to write web-platform-tests that depend on non-standard behavior. I had to debug one such last week. Furthermore Gecko mochitests have been tested against Gecko, which has itself been tested on the Web, so Gecko mochitests are far more likely to be "correct" than a test someone just wrote and only tested on, say, Servo. * Mochitests are really written assuming the full gecko featureset. Given > the total lack of isolation between asserts, they may behave rather > unexpectedly and misleadingly in a browser not having all those features. > Many use Gecko-specific features but many don't. * In the long term having multiple APIs for writing tests that people have > to learn in order to read tests is a big net negative. If we allow > mochitests to be upstreamed with a shim we should expect other vendors to > do the same, and to end up with half a dozen possible test formats. > That's fair, though it's a problem we introduced when we started adding web-platform-tests to the tree. Put it this way: when Servo needs tests for a feature, I expect it makes much more sense to take Gecko mochitests for the feature and convert them to web-platform-tests than to write new tests from scratch. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On 04/11/15 10:24, Robert O'Callahan wrote: On Wed, Nov 4, 2015 at 5:14 PM, James Graham wrote: On 03/11/15 22:08, Robert O'Callahan wrote: Why not create a Mochitest compatibility layer over testharness.js so that tests that only use SimpleTest.waitForExplicitFinish(), SimpleTest.finish(), is(), todo() and ok() can run on Servo with trivial changes? A few reasons I am skeptical of this: * Mochitests test gecko behaviour, not standardised behaviour. These can and do differ. Therefore they are even less trustworthy than the average test. I'm not sure what you mean by this. It's easy to write web-platform-tests that depend on non-standard behavior. I had to debug one such last week. Furthermore Gecko mochitests have been tested against Gecko, which has itself been tested on the Web, so Gecko mochitests are far more likely to be "correct" than a test someone just wrote and only tested on, say, Servo. I mean that mochitests are used as regression tests; they aren't necessarily testing the per-spec behaviour (which might match Blink or Edge, but not Gecko), but whatever the Gecko code implements. Of course web-platform-tests can be buggy like any other code, but they are at least intended to test the right thing. * Mochitests are really written assuming the full gecko featureset. Given the total lack of isolation between asserts, they may behave rather unexpectedly and misleadingly in a browser not having all those features. Many use Gecko-specific features but many don't. Not just use of gecko-specific (or, often spidermonkey-specific) behaviours, but also the fact that mochitests assume an assert never fails (because if one does it's a regression that needs to be fixed). In Servo, which might not implement all the features used, an assert can be expected to fail for some time until more feature work is done. This is particularly true at the moment when Servo doesn't implement the window error handler. I anticipate this impedance mismatch would cause the tests to be less useful in Servo than they are in Gecko. * In the long term having multiple APIs for writing tests that people have to learn in order to read tests is a big net negative. If we allow mochitests to be upstreamed with a shim we should expect other vendors to do the same, and to end up with half a dozen possible test formats. That's fair, though it's a problem we introduced when we started adding web-platform-tests to the tree. Put it this way: when Servo needs tests for a feature, I expect it makes much more sense to take Gecko mochitests for the feature and convert them to web-platform-tests than to write new tests from scratch. Well sure, I agree that taking mochitests as the input to a test-writing effort is a good idea. I see this as being very different to blindly shimming mochitests into the wpt harness. Having said that, however, I don't think people have complained a lot about lack of test coverage from wpt except in the areas that it doesn't cover at all i.e. dynamic changes to layout, or other human interaction. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On Wed, Nov 4, 2015 at 11:50 PM, James Graham wrote: > On 04/11/15 10:24, Robert O'Callahan wrote: > >> On Wed, Nov 4, 2015 at 5:14 PM, James Graham >> wrote: >> >> On 03/11/15 22:08, Robert O'Callahan wrote: >>> >>> Why not create a Mochitest compatibility layer over testharness.js so >>> that tests that only use SimpleTest.waitForExplicitFinish(), SimpleTest.finish(), is(), todo() and ok() can run on Servo with trivial changes? >>> A few reasons I am skeptical of this: >>> >>> * Mochitests test gecko behaviour, not standardised behaviour. These can >>> and do differ. Therefore they are even less trustworthy than the average >>> test. >>> >>> >> I'm not sure what you mean by this. It's easy to write web-platform-tests >> that depend on non-standard behavior. I had to debug one such last week. >> Furthermore Gecko mochitests have been tested against Gecko, which has >> itself been tested on the Web, so Gecko mochitests are far more likely to >> be "correct" than a test someone just wrote and only tested on, say, >> Servo. >> > > I mean that mochitests are used as regression tests; they aren't > necessarily testing the per-spec behaviour (which might match Blink or > Edge, but not Gecko), but whatever the Gecko code implements. Of course > web-platform-tests can be buggy like any other code, but they are at least > intended to test the right thing. I think it's uncommon for mochitests to intentionally be stricter than what the spec requires ... excluding cases where the spec is known to be inadequate. It's easy to be accidentally more strict, but that's true for WPT too. > * Mochitests are really written assuming the full gecko featureset. Given >> >>> the total lack of isolation between asserts, they may behave rather >>> unexpectedly and misleadingly in a browser not having all those features. >>> >>> >> Many use Gecko-specific features but many don't. >> > > Not just use of gecko-specific (or, often spidermonkey-specific) > behaviours, but also the fact that mochitests assume an assert never fails > (because if one does it's a regression that needs to be fixed). In Servo, > which might not implement all the features used, an assert can be expected > to fail for some time until more feature work is done. This is particularly > true at the moment when Servo doesn't implement the window error handler. I > anticipate this impedance mismatch would cause the tests to be less useful > in Servo than they are in Gecko. > That makes sense. > > * In the long term having multiple APIs for writing tests that people have >> >>> to learn in order to read tests is a big net negative. If we allow >>> mochitests to be upstreamed with a shim we should expect other vendors to >>> do the same, and to end up with half a dozen possible test formats. >>> >>> >> That's fair, though it's a problem we introduced when we started adding >> web-platform-tests to the tree. >> >> Put it this way: when Servo needs tests for a feature, I expect it makes >> much more sense to take Gecko mochitests for the feature and convert them >> to web-platform-tests than to write new tests from scratch. >> > > Well sure, I agree that taking mochitests as the input to a test-writing > effort is a good idea. I see this as being very different to blindly > shimming mochitests into the wpt harness. Having said that, however, I > don't think people have complained a lot about lack of test coverage from > wpt except in the areas that it doesn't cover at all i.e. dynamic changes > to layout, or other human interaction. To pick a couple of areas I work on: for CSSOM-Views for example there is practically no coverage at all. The media tests are better but still very limited compared to what we test in mochitests. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On 04/11/15 11:12, Robert O'Callahan wrote: Well sure, I agree that taking mochitests as the input to a test-writing effort is a good idea. I see this as being very different to blindly shimming mochitests into the wpt harness. Having said that, however, I don't think people have complained a lot about lack of test coverage from wpt except in the areas that it doesn't cover at all i.e. dynamic changes to layout, or other human interaction. To pick a couple of areas I work on: for CSSOM-Views for example there is practically no coverage at all. The media tests are better but still very limited compared to what we test in mochitests. It would be great to have a record of some areas where we know that web-platform-tests has missing coverage; we occasionally get people looking for areas where they can make useful test contributions and asking what's required. Can you file some issues on GitHub, possibly pointing to the relevant mochitests that we could draw from? ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On Thu, Nov 5, 2015 at 12:17 AM, James Graham wrote: > On 04/11/15 11:12, Robert O'Callahan wrote: > >> Well sure, I agree that taking mochitests as the input to a test-writing >>> effort is a good idea. I see this as being very different to blindly >>> shimming mochitests into the wpt harness. Having said that, however, I >>> don't think people have complained a lot about lack of test coverage from >>> wpt except in the areas that it doesn't cover at all i.e. dynamic changes >>> to layout, or other human interaction. >>> >> >> >> To pick a couple of areas I work on: for CSSOM-Views for example there is >> practically no coverage at all. The media tests are better but still very >> limited compared to what we test in mochitests. >> > > It would be great to have a record of some areas where we know that > web-platform-tests has missing coverage; we occasionally get people looking > for areas where they can make useful test contributions and asking what's > required. Can you file some issues on GitHub, possibly pointing to the > relevant mochitests that we could draw from? Sure. https://github.com/w3c/web-platform-tests/issues/2304 The media tests are better than I thought --- I found more. They don't test the variety of problematic media files that our mochitests do, but maybe that's not in scope? Should we be worried that regressions in the media stack seldom trigger W test failures on mozilla-inbound but often trigger mochitest failures? Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On 04/11/15 11:41, Robert O'Callahan wrote: Sure. https://github.com/w3c/web-platform-tests/issues/2304 Thanks! The media tests are better than I thought --- I found more. They don't test the variety of problematic media files that our mochitests do, but maybe that's not in scope? Should we be worried that regressions in the media stack seldom trigger W test failures on mozilla-inbound but often trigger mochitest failures? I consider anything that might affect browser interop or quality in-scope, as long as it can be run cross-browser and it's clear what the expected result is. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)
On Thu, Nov 5, 2015 at 12:44 AM, James Graham wrote: > On 04/11/15 11:41, Robert O'Callahan wrote: > >> The media tests are better than I thought --- I found more. They don't >> test >> the variety of problematic media files that our mochitests do, but maybe >> that's not in scope? Should we be worried that regressions in the media >> stack seldom trigger W test failures on mozilla-inbound but often trigger >> mochitest failures? >> > > I consider anything that might affect browser interop or quality in-scope, > as long as it can be run cross-browser and it's clear what the expected > result is. OK: https://github.com/w3c/web-platform-tests/issues/2305 Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
