To match Safari compat, we need to pass all the layout tests that are not inherently Safari specific. So essentially that means having 0 failing tests and 0 deferred tests. The point of deferring is just so we can prioritize some tests over others as we fix them. In an ideal world down the road, all our deferred tests will be for features that we have yet to turn on because they're not quite finished (e.g. Databases, Media elements, etc). Alternately, I hate to complicate the test lists even more, but it seems like maybe we really should add yet another property for layout tests, e.g., UNIMPLEMENTED, for the features that aren't ready to turn on. Most of the tests we currently have marked as DEFER would need to be changed over to UNIMPLEMENTED. Then DEFER is really just there so we can prioritize regressions over new tests.
Ojan On Thu, Feb 19, 2009 at 4:03 PM, Evan Martin <[email protected]> wrote: > On Thu, Feb 19, 2009 at 3:56 PM, Peter Kasting <[email protected]> > wrote: > > On Thu, Feb 19, 2009 at 3:56 PM, Peter Kasting <[email protected]> > > wrote: > >> > >> To the degree that new upstream tests represent "stuff we're shipping > >> should actually work as advertised", I would prefer not to defer it. > > > > One more I forgot. If we're trying to not diverge from Safari too much > (for > > web authors' sake), it behooves us to pass tests that they pass if it's > > relevant to web compat. > > I think I'm with Peter -- we should only defer tests that we really > intend to defer. > I imagine there are two classes of tests coming in from upstream: > - tests that cover regressions changes > - tests that cover new features that we don't yet support > > It's up to a human to mark the second category DEFER, but we shouldn't > do it blindly. > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
