<div class="gmail_quote">On Tue, Jul 5, 2011 at 5:46 PM, Dirk Pranke <span dir="ltr"><<a href="mailto:dpranke@chromium.org">dpranke@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On Tue, Jul 5, 2011 at 5:40 PM, Dirk Pranke <<a href="mailto:dpranke@chromium.org">dpranke@chromium.org</a>> wrote:<br>
> On Tue, Jul 5, 2011 at 5:16 PM, Ojan Vafai <<a href="mailto:ojan@chromium.org">ojan@chromium.org</a>> wrote:<br>
>> On Tue, Jul 5, 2011 at 4:51 PM, Dirk Pranke <<a href="mailto:dpranke@chromium.org">dpranke@chromium.org</a>> wrote:<br>
>>><br>
>>> On Tue, Jul 5, 2011 at 1:53 PM, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>> wrote:<br>
>>> > On Jul 5, 2011 1:26 PM, "Dirk Pranke" <<a href="mailto:dpranke@chromium.org">dpranke@chromium.org</a>> wrote:<br>
>>> >> > However, we can do the same with the existing testing framework since<br>
>>> >> > we<br>
>>> >> > can<br>
>>> >> > associate a test with a bug by adding a line like this:<br>
>>> >> > BUGWK????? my-test.html = PASS<br>
>>> >><br>
>>> >> You lost me here ...<br>
>>> ><br>
>>> > What I meant is that we can use test_expectations.txt to annotate a test<br>
>>> > with a bug number even if we overrode -expected.txt by adding that line.<br>
>>> > This allows us to track of tests with bad expected results while also<br>
>>> > allowing us to catch any changes in actual result.<br>
>>> ><br>
>>><br>
>>> Ah. That makes a lot of sense. Good idea.<br>
>>><br>
>>> On Tue, Jul 5, 2011 at 3:46 PM, Ojan Vafai <<a href="mailto:ojan@chromium.org">ojan@chromium.org</a>> wrote:<br>
>>> > We could simplify the syntax somewhat to not require the "= PASS" at the<br>
>>> > end. We could also change the bug format to be actual links instead<br>
>>> > (e.g.<br>
>>> > <a href="http://webkit.org/b/12345" target="_blank">webkit.org/b/12345</a> and <a href="http://crbug.com/12345" target="_blank">crbug.com/12345</a>).<br>
>>> > <a href="http://webkit.org/b/12345" target="_blank">webkit.org/b/12345</a> : fast/canvas/canvastest.html<br>
>>> > You can also list multiple bug per line:<br>
>>> > <a href="http://webkit.org/b/12345" target="_blank">webkit.org/b/12345</a> <a href="http://webkit.org/b/33333" target="_blank">webkit.org/b/33333</a> : fast/canvas/canvasttest.html<br>
>>> > That seem OK?<br>
>>><br>
>>> I'm not so much a fan of this change. It's more typing and I'm not<br>
>>> sure if it makes anything much easier for the user (maybe viewing in a<br>
>>> text editor that will automatically hyperlink the text, I guess).<br>
>>><br>
>>> Note that the current syntax does support multiple bugs per line<br>
>>> (although not the hyperlink syntax you propose); I'm sure you knew<br>
>>> that, so perhaps you were just mentioning that for the others on the<br>
>>> list.<br>
>><br>
>> One of the problems with the current format is that it's excessively<br>
>> complicated. Avoiding magic syntax and just using URLs makes it so there is<br>
>> less specialized syntax to make sense of. It also has the potential<br>
>> advantages you mention (e.g. you could copy-paste the text into your<br>
>> browser's address bar), but that's secondary.<br>
>><br>
><br>
> I keep hearing that the syntax is "excessively complicated". It's a<br>
> pretty simple syntax, but even you think that it is complicated, but<br>
> in what way is it excessively so, given that we actively use all of<br>
> the features it supports?<br>
><br>
> Also note that changing BUGXXX to a URL doesn't necessarily make it<br>
> less complicated; It may actually make it more complicated, since you<br>
> would either have to parse URLs out from the tokens or decide what<br>
> sort of URL-like syntax you were going to allow.<br></div></div></blockquote><div><br></div><div>Most people's interaction with this file is brief and infrequent. So, every time they encounter it again, they need to figure out how it all works again.  The bug syntax isn't the most confusing part of the syntax, but it adds a bit to the confusion.</div>

<div><br></div><div>I think people are more confused with the various failure types. If we move to a model where we check in failing expectations and just list them with the bug number, I would be fine with going back to a world without fine-grained failure types (i.e. we'd just have PASS, FAIL, TIMEOUT and CRASH).</div>

<div><br></div><div>People are also confused by dealing with the multitude of different platforms, but I don't have concrete suggestions on how to improve that situation.</div><div><br></div><div>Finally, people are confused by how SLOW works. I'd much rather we just increase the default timeout and give a shorter timeout for tests that are listed as having TIMEOUT expectations. That maintains the benefits to bot cycle time without needing to manually maintain a list of slow tests.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">My apologies if this came off sharper than I had intended; I only</div></div></blockquote>

<div><br></div><div>No worries. Wasn't offended.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
meant to focus on specific suggestions (like your URL change), rather<br>
than vague comments. I am certainly open to anything that makes things<br>
simpler, I just don't know how much there is to simplify without also<br>
losing functionality. I'm also open to losing functionality that isn't<br>
really that valuable, just that that needs to be weighed in,<br>
obviously.<br></blockquote><div><br></div><div>I think we agree here. I've just become more and more convinced that some loss of functionality may be worth the benefit of people being able to make more sense of this and the benefit of just having fewer lines in this file.</div>

<div></div></div><br><div>Ojan</div>