That builder just had a stuck build. I canceled the build, and things
seem better.
I believe I also fixed the bug which was hanging the commit-queue and
chromium-linux EWS bots. Those should return to normal by morning
(just in time for the rush!).
-eric
On Sun, Apr 8, 2012 at 10:56 PM, Eric
Yes Thanks, its running now.
-Sravan.
On Mon, Apr 9, 2012 at 1:49 PM, Eric Seidel e...@webkit.org wrote:
That builder just had a stuck build. I canceled the build, and things
seem better.
I believe I also fixed the bug which was hanging the commit-queue and
chromium-linux EWS bots. Those
Hi All,
It is observed that if changes are made in Codegenerator*.pm we need to
rebase results of run-bindings-tests.
Many times authors forgot to update these binding results.
IMO we should add check in ./check-webkit-style to warn/(give a chance)
author to run run-bindings-tests if
IMO we should add check in ./check-webkit-style to warn/(give a chance)
author to run run-bindings-tests if Codegenerator is modified.
+1 to the idea. I think that it would make sense to warn if any file
under WebCore/bindings/ is changed.
Another idea might be to run ./run-bindings-tests in
[Sending from a correct mail address...]
IMO we should add check in ./check-webkit-style to warn/(give a chance)
author to run run-bindings-tests if Codegenerator is modified.
+1 to the idea. I think that it would make sense to warn if any file
under WebCore/bindings/ is changed.
Another
We have discussed this before:
https://lists.webkit.org/pipermail/webkit-dev/2011-September/017868.html
A better change would be for us to generate the diff on EWS, and get rid of
binding tests step from build bots since they aren't really testing
anything. The primary use case of
Also note Maciej's proposal about moving it to a build step.
Either way, it shouldn't be ran as a test step on build bots.
- Ryosuke
On Mon, Apr 9, 2012 at 9:18 AM, Ryosuke Niwa rn...@webkit.org wrote:
We have discussed this before:
[From the correct email]
On Mon, Apr 9, 2012 at 12:26 PM, Jarred Nicholls jar...@sencha.com wrote:
On Mon, Apr 9, 2012 at 12:18 PM, Ryosuke Niwa rn...@webkit.org wrote:
We have discussed this before:
https://lists.webkit.org/pipermail/webkit-dev/2011-September/017868.html
A better change
On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 15, 2009, at 1:29 PM, Sverrir Á. Berg wrote:
Hi Adam,
Thanks for the links. These are simply exposing the functions as a formal a
API's. I understand that you typically don't want to change externally
exposed
Hi all,
The latest thread on run-bindings-tests has reminded me that a few
months ago we discussed having one top-level script that would run
*all* of the tests in the repository (perl tests, python tests,
new-run-webkit-tests, unit tests, run-bindings-tests, etc.), but as
far as I know, no one
Hi all,
Recently I've noticed more people making changes and adding test
failure suppressions to various ports' test_expectations.txt files.
This is great!
However, I don't think we have an agreement over what the best
practices are here, so I thought I'd list out what I thought they
were, and
On Mon, Apr 9, 2012 at 3:02 PM, James Robinson jam...@google.com wrote:
3) Don't use test_expectations.txt to suppress failures across a
single cycle of the bot, just so you can gather updated baselines
without the tree going red. While it might seem that you're doing tree
maintainers a favor,
On Apr 9, 2012, at 12:27 PM, Adam Barth wrote:
On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 15, 2009, at 1:29 PM, Sverrir Á. Berg wrote:
Hi Adam,
Thanks for the links. These are simply exposing the functions as a formal a
API's. I understand that you
On Mon, Apr 9, 2012 at 3:24 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 9, 2012, at 12:27 PM, Adam Barth wrote:
On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 15, 2009, at 1:29 PM, Sverrir Á. Berg wrote:
Hi Adam,
Thanks for the links. These are simply
On Monday 09 April 2012 22:42:33 Dirk Pranke wrote:
Hi all,
Recently I've noticed more people making changes and adding test
failure suppressions to various ports' test_expectations.txt files.
This is great!
Hi Dirk,
It would be good to have a page describing the right thing to do for each
In my ideal world, you would be able to get updated baselines *prior*
to trying to land a patch. This is of course not really possible today
for any test that fails on multiple ports with different results, as
it's practically impossible to run more than a couple of ports by
hand, and we
On Mon, Apr 9, 2012 at 3:50 PM, Julien Chaffraix jchaffr...@webkit.orgwrote:
If there's consensus in the mean time that it is better on balance to
check in suppressions, perhaps we can figure out a better way to do
that. Maybe (shudder) a second test_expectations file? Or maybe it
would
On Mon, Apr 9, 2012 at 3:50 PM, Julien Chaffraix jchaffr...@webkit.org wrote:
In my ideal world, you would be able to get updated baselines *prior*
to trying to land a patch. This is of course not really possible today
for any test that fails on multiple ports with different results, as
it's
If there's consensus in the mean time that it is better on balance to
check in suppressions, perhaps we can figure out a better way to do
that. Maybe (shudder) a second test_expectations file? Or maybe it
would be better to actually check in suppressions marked as REBASELINE
(or something
19 matches
Mail list logo
