In the spirit of trying to fix all the layout tests that represent real regressions since our initial launch, I've just committed a changelist that defers the tests that are failing that are new to webkit since the revision of our launch or whose expectations changed upstream (the latter was only a couple tests, the former was almost 80 tests). If people think this is an awful idea, I can rollback.
I don't think it makes sense to block releases to the stable channel on new tests that we've never passed. My biggest concern with each release is breaking sites that previously used to work in Chrome. New tests, for the most part, don't represent regressions like that. Does it make sense to make a policy of deferring new, failing tests from a webkit merge by default. The person doing the merge should put a good faith effort into getting it fixed, but it shouldn't block cutting a release. Eventually we'll get to a point where we only have deferred tests left and we can start tackling that long list of tests without having it hinder our ability to push releases to the stable channel. Ojan --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
