On Fri, May 19, 2017 at 10:17 AM, youenn fablet <[email protected]> wrote: > > > Le ven. 19 mai 2017 à 09:44, Anne van Kesteren <[email protected]> a écrit : >> >> On Fri, May 19, 2017 at 5:11 PM, youenn fablet <[email protected]> wrote: >> > When a spec gets updated, the WPT tests will ideally be updated at the >> > same >> > time. >> > The updated tests will no longer ensure non-regression until the browser >> > implements the new behavior. >> >> Ideally if importing test updates results in failures those end up >> being tracked as new bugs. I realize that's not how it works today, >> but that's how it should work I think. > > > Right, and that is very good as long as there is effort to match the > implementation with the spec. > Until the bug is fixed, regressions related to the no-longer compliant > behavior might not be caught by WPT. > >> >> >> >> > The same applies to deprecated features for which WPT tests might be >> > removed >> > for instance. >> >> In this case it's expected that a "historical" test is added that >> tests the feature isn't supported, so there's still coverage. > > > Sure, it is good to test conformance, but there is no longer regression > testing on the deprecated feature behavior itself. > Ideally, this would require tighter syncing between the browsers. Might have > positive and/or negative consequences.
I don't think we should be changing anything about our process to deprecate a feature based on changes to web platform tests or its limitations. If web platform tests end up deleting tests that we decide to continue to support, we should keep them elsewhere in WebKit repository instead of deleting those features. I would most vocally and strongly oppose to making any feature or policy decisions in WebKit solely based on changes to or processes in web platform tests. - R. Niwa _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
