I think it's fine to add some support for sampling "unexpected"
timeouts. However if the timeout is expected in test_expectations, we
shouldn't bother to sample. :)
Then again, since new-run-webkit-tests is all parallel and stuff we
need not block for the sample like how the current run-webkit-te
https://bugs.webkit.org/show_bug.cgi?id=37402
On Sat, Apr 10, 2010 at 8:55 PM, Maciej Stachowiak wrote:
> The reason for sampling timeouts is so that you can diagnose what happened
> more easily when you get an unexpected timeout. Same reason we save
> backtraces from crashes. Having some expecte
The reason for sampling timeouts is so that you can diagnose what
happened more easily when you get an unexpected timeout. Same reason
we save backtraces from crashes. Having some expected timeouts does
not remove the need to diagnose regressions that manifest as a timeout.
On Apr 10, 201
new-run-webkit-tests does not sample tests when they timeout. timeout
is a perfectly "reasonable" test expectation. new-run-webkit-tests is
about running all the tests and making sure their behavior matches
what we have in test_expectations.txt. This is unlike
run-webkit-tests for which the only
10.04.2010, в 17:44, Eric Seidel написал(а):
Yes, I think we should keep Chromium's default low timeout. Having
such a low timeout allows new-run-webkit-tests to easily run all flaky
tests every time, even ones which occasionally timeout.
Does new-run-webkit-tests not sample tests that time
On Sat, Apr 10, 2010 at 5:44 PM, Eric Seidel wrote:
> We just need to mark slow tests as SLOW in
> LayoutTests/platform/mac/test_expectations.txt
Done.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinf
Yes, I think we should keep Chromium's default low timeout. Having
such a low timeout allows new-run-webkit-tests to easily run all flaky
tests every time, even ones which occasionally timeout.
We just need to mark slow tests as SLOW in
LayoutTests/platform/mac/test_expectations.txt
On Fri, Apr
On Fri, Apr 9, 2010 at 5:03 PM, Yuzo Fujishima wrote:
> Sorry, (mostly) false positives.
> I've synced to r57383 and all but 3 failures are gone.
> I don't see /tmp/layout-test-results. Where are the errors logged?
> The following is the console output.
> $ ./WebKitTools/Scripts/new-run-webkit-tes
Recording to a local file the order in which tests are run on each thread
should be relatively trivial. I filed
https://bugs.webkit.org/show_bug.cgi?id=37396. That will help with flakiness
that is simply order dependent, which I think is most of it. It won't help
with flakiness that has to do with
By popular demand, Ojan recently wrote a patch that makes
"webkit-patch land" no build or test before committing. If you'd like
to build and test your patch before landing, you can use the --build
and --test flags. (The commit-queue will continue to build and test
before landing patches.)
Adam
_
Greetings,
I am having a go at compiling kde4.4.2. I am now trying to build webkit for
KDE4.4.2 (pure-64bit -non-multilib -amd64 linux setup). (it is needed by
google-gadgets) I downloaded qtwebkit from
http://gitorious.org/+qtwebkit-developers/webkit/qtwebkit
and it compiles OK with the
>
> I've already upgraded one of my repositories to the latest SVN and resolved
> the conflicts and incorporated the changes. I just need to merge that with
> some changes in my other repository, but it's not a problem and won't take
> long.
>
>
I'm glad to hear that. I thought it would be harder (
Hi,
On 2010-04-10 at 00:26:36 [+0200], Maxime Simon
wrote:
> I'm "officially" the main maintainer of the Haiku port. But
> considering my university course I have little time to work on it.
> (I had plan to do so next summer though.) Another Haiku developer,
> Stephan Assmus, did lately some gre
13 matches
Mail list logo
