Seems to me that the ideal situation down the road would be a buildbot that lives on tip of tree webkit.org, runs all the tests and every green build auto-updates the webkit revision we pull. Even in that case, we will have *at least* a couple build breakages a day from new tests that we don't pass. I'm OK with needing manual intervention to green the build and get the autoupdating working again (i.e. add the tests to the test lists) and we should work hard to make sure we fix the tests as soon as possible, but we still shouldn't block cutting a release on these tests.
So, while unforking will make the burden of keeping up considerably less painful, we'll still need considerable effort devoted towards keeping the tests passing. Ojan On Fri, Feb 20, 2009 at 12:16 PM, Pam Greene <[email protected]> wrote: > Do we plan to live on the edge of the wave once we're entirely unforked, > and never do merges again? > - Pam > > > On Fri, Feb 20, 2009 at 11:01 AM, Darin Fisher <[email protected]> wrote: > >> This sounds good to me as a temporary measure while we are still doing >> merges. >> We are supposed to be unforked by the end of the quarter, right? ;-) >> >> -Darin >> >> >> On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai <[email protected]> wrote: >> >>> >>> 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 -~----------~----~----~----~------~----~------~--~---
