[webkit-dev] Simplifying syntax in test_expectations.txt (bug 86691)

[Dirk Pranke]

On Wed, May 16, 2012 at 9:08 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Hi,
>
> There has been some complaints / discussions about how syntax in
> test_expectations.txt is confusing (and I agree with you) on webkit-dev and
> at contributors' meeting.
>
> So I have a patch on https://bugs.webkit.org/show_bug.cgi?id=86691 to
> simplify syntax in test_expectation.txt as follows:
>
> Bug modififers are bug numebr themselves for WebKit and URLs for non-WebKit
> bugs
> e.g. 12345 and crbug.com/12345 instead of BUGWK12345 and BUGCR12345
> respectively
> : and = delimiters are no longer needed
> All modifiers and expectations show before test name
> e.g. 12345 WIN MAC TEXT IMAGE test.html instead of BUGWK12345 WIN MAC :
> test.html = TEXT IMAGE
>

As I've commented in the bug, I'm not a fan of the proposed syntax above :(

>
> Note:
> Just listing a test DOES NOT automatically skip a test even after my patch
> is applied:
> test.html
> will result in a warning, and we still expect it to pass. I'll cite Ojan's
> comment for the rationale:
>>
>> The bigger problem with implying SKIP, is how do you decide when SKIP
>> isn't applied? That needs some hidden set of rules that's too complicated
>> IMO.
>

As I've also noted in the bug, I don't follow this ... how is this any
more complicated than "if there's no modifier, default to SKIP"? Why
is defaulting to PASS any easier?

>
> We can come back to this problem later if we wanted but let us start from
> the above cleanups first.
>
> For those who are interested, we're also going to rename
> test_expectations.txt to something more WebKitty
> on https://bugs.webkit.org/show_bug.cgi?id=86690.
>

I would have preferred it if you'd phrased this as "proposed renaming
test_expectations.txt" :). It's not clear to me that renaming it to
any of the other suggestions thus far are improvements, and there are
lots of people (and scripts) used to the existing names.

I'm sorry for sounding negative, but a lot of this feels like
superficial stylistic tweaks, so I would be inclined to leave things
the way they are unless there is a clear consensus that people prefer
the new syntax?

-- Dirk