No, I'm working on it now. We need stable APIs ASAP so that we can do the stable and tip-of-tree separation before we have finished unforking. We should be able to have a stable third_party/WebKit and a close to tip-of-tree third_party/WebKit. That will help us do releases in the short term.
-Darin On Fri, Feb 20, 2009 at 12:37 PM, Ojan Vafai <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
