>>> 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
On Mon, Apr 9, 2012 at 3:50 PM, Julien Chaffraix 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 practically imp
On Mon, Apr 9, 2012 at 3:50 PM, Julien Chaffraix wrote:
>
> > 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
> 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 2:56 PM, Dana Jansens wrote:
> On Mon, Apr 9, 2012 at 5:42 PM, Dirk Pranke 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 t
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
On Mon, Apr 9, 2012 at 3:24 PM, Maciej Stachowiak wrote:
> On Apr 9, 2012, at 12:27 PM, Adam Barth wrote:
>> On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak wrote:
>>> On Apr 15, 2009, at 1:29 PM, Sverrir Á. Berg wrote:
Hi Adam,
Thanks for the links. These are simply exposing the fu
On Apr 9, 2012, at 12:27 PM, Adam Barth wrote:
> On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak 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 typica
On Mon, Apr 9, 2012 at 3:02 PM, James Robinson 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, in my exp
>
> 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, in my experience this just makes things confusing
> and it's bette
On Mon, Apr 9, 2012 at 5:42 PM, Dirk Pranke 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, in my experienc
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
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 ha
On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak 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 API's but
[From the correct email]
On Mon, Apr 9, 2012 at 12:26 PM, Jarred Nicholls wrote:
> On Mon, Apr 9, 2012 at 12:18 PM, Ryosuke Niwa wrote:
>
>> We have discussed this before:
>> https://lists.webkit.org/pipermail/webkit-dev/2011-September/017868.html
>>
>> A better change would be for us to genera
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 wrote:
> We have discussed this before:
> https://lists.webkit.org/pipermail/webkit-dev/2011-September/017868.html
>
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 run-bindings-tes
[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
> 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
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 Codegene
Yes Thanks, its running now.
-Sravan.
On Mon, Apr 9, 2012 at 1:49 PM, Eric Seidel 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 should ret
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 S
22 matches
Mail list logo