[webkit-dev] chromium-cg-mac results

[Adam Barth]

To update webkit-dev: chromium-cg-mac is now gone.

Thanks everyone,
Adam


On Wed, Jan 4, 2012 at 8:05 AM, Elliot Poger <epoger at chromium.org> wrote:
> Filed https://bugs.webkit.org/show_bug.cgi?id=75548 ('[rollup] remove
> chromium-cg-mac baselines')
>
>
> On Wed, Jan 4, 2012 at 10:37 AM, Adam Barth <abarth at webkit.org> wrote:
>>
>> On Wed, Jan 4, 2012 at 6:10 AM, Elliot Poger <epoger at chromium.org> wrote:
>> > I agree that it is reasonable (and a good idea) to remove the
>> > chromium-cg-mac expectations from WebKit now, and I am willing to take
>> > the
>> > lead on doing so (although I will need help from WebKit committers).
>>
>> Sounds like a good plan.  I'm happy to help.  Let's coordinate off-list.
>>
>> Thanks,
>> Adam
>>
>>
>> > Please let me know if anyone agrees/disagrees with the following steps
>> > to do
>> > so:
>> >
>> > 1. remove the following buildbots that rely on chromium-cg-mac
>> > expectations
>> > (otherwise, they will start failing once the CG expectations disappear):
>> >
>> >
>> > http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28deps%29
>> >
>> > http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28deps%29
>> >
>> > http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29
>> >
>> > http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29
>> >
>> > http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29
>> >
>> > http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28dbg%29
>> >
>> > http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%281%29
>> >
>> > http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%282%29
>> >
>> > http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28dbg%29
>> >
>> > 2. remove the LayoutTests/platform/*-cg-* directories from the WebKit
>> > repo
>> >
>> > 3. remove any CG-specific entries from
>> > LayoutTests/platform/chromium/test-expectations.txt
>> >
>> > 4. remove any CG-specific test code from the Tools/Scripts/webkitpy tree
>> >
>> >
>> > On Wed, Jan 4, 2012 at 12:01 AM, David Levin <levin at chromium.org> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jan 3, 2012 at 8:33 PM, Dirk Pranke <dpranke at chromium.org>
>> >> wrote:
>> >>>
>> >>> On Tue, Jan 3, 2012 at 3:28 PM, Adam Barth <abarth at webkit.org> wrote:
>> >>> > On Tue, Jan 3, 2012 at 3:22 PM, Nico Weber <thakis at chromium.org>
>> >>> > wrote:
>> >>> >> On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth <abarth at webkit.org>
>> >>> >> wrote:
>> >>> >>> It looks like Chromium Mac has successfully moved to Skia.
>> >>> >>
>> >>> >> I'd wait with this assessment until a version of Chrome with Skia
>> >>> >> has
>> >>> >> shipped to stable. Things are looking really good so that should be
>> >>> >> smooth sailing, but it's a bit early to say we're "successfully
>> >>> >> moved"
>> >>> >> :-)
>> >>> >
>> >>> > Fair enough.  However, I believe the Skia transition plan called for
>> >>> > removing the chromium-cg-mac expectation much earlier than a Skia
>> >>> > build shipping to stable.  Originally, we were only supposed to have
>> >>> > to maintain both sets of expectations for about a month.  The
>> >>> > transition has taken longer than expected, but it seems like we have
>> >>> > sufficient confidence in Skia now that we can remove the
>> >>> > chromium-cg-mac expectations.
>> >>> >
>> >>>
>> >>> Has the skia transition hit beta yet? It seems like as soon as we get
>> >>> it onto a version that is pointing to a branched version of webkit, we
>> >>> should be completely safe to remove the directories on trunk (frankly,
>> >>> I'd agree with Adam that it's probably safe to remove it now, since we
>> >>> can always add them back in if we have to, but I can compromise as
>> >>> well).
>> >>
>> >>
>> >> Remove it.
>> >>
>> >> It is a cost on everyone who enlists in WebKit. Those of us who aren't
>> >> creating new enlistments are not affected much but that doesn't mean it
>> >> isn't costly.
>> >>
>> >> dave
>> >>
>> >
>
>