Realistically though, the point at which we have a stable api is at least another quarter out, right? So, there are two proposals on the table: 1. From now on, defer any non-security/crash tests we've never passed (i.e. new tests from webkit merges that fail) 2. Same as proposal 1, except we also add a NOTIMPLEMENTED option for the tests of features we haven't turned on yet.
Preferences? I'm happy to make either one happen. Ojan On Fri, Feb 20, 2009 at 12:33 PM, Darin Fisher <[email protected]> wrote: > Yes. We will have a stable API (a real WebKit layer) that lives in > svn.webkit.org. That will enable us to point the chromium source at > either a stable version of WebKit or the latest tip-of-tree WebKit. The set > of developers who work on WebKit will live on tip-of-tree and ensure that it > is maintained. The rest of the Chrome developers will be able to work free > of the usual WebKit churn. When we identify a good WebKit, we can roll DEPS > to make everyone use that version by default. In other words, we will be > able to work with WebKit just as we do with V8 today. > -Darin > > 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 -~----------~----~----~----~------~----~------~--~---
