Re: [chromium-dev] changes to specifying test names (and test_expectations.txt) for Layout tests

51 AM, Ojan Vafai wrote: > Ugh. It looks like the data all got clobbered as well. That should only > happen if the JSON file got corrupted somehow. Not really sure how that > happened. In either case, all there is to do right now is to fix the windows > paths. > > > On Thu

Re: [chromium-dev] changes to specifying test names (and test_expectations.txt) for Layout tests

Ugh. It looks like the data all got clobbered as well. That should only happen if the JSON file got corrupted somehow. Not really sure how that happened. In either case, all there is to do right now is to fix the windows paths. On Thu, Jan 14, 2010 at 11:43 AM, Ojan Vafai wrote: > Actually,

Re: [chromium-dev] changes to specifying test names (and test_expectations.txt) for Layout tests

Actually, the data is messed up. It's the windows bots. The path isn't being made relative properly. It's getting full windows paths in the results.json file. We'll need to do a cleanup pass. Dirk, you want to do that, or should I? On Thu, Jan 14, 2010 at 10:40 AM, Ojan Vafa

[chromium-dev] layout test dashboard and other test types

I finally wrote a mini-design doc for the layout test dashboard . Getting this to work for other tests (e.g. browser_tests, unit_tests, etc) would be a pretty small amount of Python work. If anyone is interested in

[chromium-dev] Re: all chrome/ LayoutTests have been upstreamed or removed

Does this include the pending/ directory as well? On Fri, Dec 18, 2009 at 6:59 PM, Dirk Pranke wrote: > I have either deleted or submitted patches to upstream all of the > remaining tests under chrome/ . There are a few that appear to be > platform-specific, but most weren't. Assuming they clear

Re: [chromium-dev] The plan for upstreaming all of our layout tests infrastructure

(3) forks run_webkit_tests.py upstream. (4) Make it possible to run the tests with TestShell while run_webkit_tests.py is upstream. (5) Change the chromium bots to use the upstream run_webkit_tests.py That all seems fine. But then we have to leave the forked copy in there until the last step (13)

[chromium-dev] Re: [chromium-reviews] Re: By popular (?) demand, add some more options for different styles of output.... (issue495006)

am webkit. In a followup patch, I'll make it print out each shard as we go for the default case of sharding by directory. Ojan On Mon, Dec 14, 2009 at 4:46 PM, Ojan Vafai wrote: > +chromium-dev > > I don't think having a third mode makes sense. We should have terse > (default

[chromium-dev] Re: [chromium-reviews] Re: By popular (?) demand, add some more options for different styles of output.... (issue495006)

logging of unexpected > results a separate feature (since we log the unexpected results at the > end, I don't think they always need to be in the middle). I don't like > (9), and I like (10) even less, since both of these options actually > undo much of my previous work an

Re: [chromium-dev] Best Practices when disabling tests?

On Mon, Dec 14, 2009 at 10:55 AM, Ojan Vafai wrote: > On Mon, Dec 14, 2009 at 10:36 AM, David Levin wrote: > >> On Mon, Dec 14, 2009 at 10:24 AM, Scott Hess wrote: >> >>> Also, last time I was looking through some valgrind suppressions, I >>> found that of

Re: [chromium-dev] revised output for run_webkit_tests

Sigh. Now from the right email address. On Fri, Dec 11, 2009 at 11:36 AM, Ojan Vafai wrote: > I thought we had agreed on printing out any unexpected failures in > real-time, no? > > Also, I do think it would be worthwhile to print each directory as it > finishes. We're

Re: [chromium-dev] Extensions and the Mac

On Thu, Dec 10, 2009 at 4:38 PM, Avi Drissman wrote: > On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin wrote: > >> Distributing binaries on Linux = sadness, as the Flash guys will tell >> you. >> [...] >> >> In summary, all I offer you is more problems and the plea that we >> should really really

[chromium-dev] speed or flakiness

Summary: We're increasing sharding for running webkit tests and it's increasing test flakiness a bit. 1. Is the tradeoff of (hopefully) temporary increased flakiness worth the speed gains? We retry these failures, so they rarely actually turn the bots red, 2. The flakiness is temporary only if we

[chromium-dev] Re: Something smells weird on the buildbot

On Thu, Dec 3, 2009 at 10:21 AM, Dimitri Glazkov wrote: > How about we turn red for unexpected crashiness? > Makes sense to me. We can just not retry tests that unexpectedly crash. On Thu, Dec 3, 2009 at 10:09 AM, Dirk Pranke wrote: > On Thu, Dec 3, 2009 at 10:07 AM, Ojan Vaf

[chromium-dev] layout test dashboard moar better too!

A few changes to the layout test dashboard you might not be aware of if you haven't used it in a while: - You can see the expected results, actual results and diffs between the two for a given test. This is especially useful when doing rebaseline code reviews. The results shown are the re

[chromium-dev] webkit test flakiness moar better now

As of yesterday, we now retry any unexpected webkit failures. If they pass the second time around, then we turn the bot orange and list the unexpected flaky tests on the waterfall and at the end of the stdio of run_webkit_test.py. If they fail the second time around we turn the bot red as usual. Q

sheriff's keep the tree *open* WAS: [chromium-dev] More sheriffs?

On Fri, Nov 13, 2009 at 1:25 PM, Peter Kasting wrote: > On Fri, Nov 13, 2009 at 1:15 PM, Finnur Thorarinsson wrote: > >> If the sheriff load is too much for two people to devote 100% of their >> time to, then there is something wrong with the process. >> > > It's clearly too much, given that I ha

Re: [chromium-dev] scrolling a text area with shift-pgdn

On Thu, Nov 12, 2009 at 9:46 AM, Peter Kasting wrote: > On Thu, Nov 12, 2009 at 9:41 AM, Ojan Vafai wrote: > >> This is a long-standing WebKit bug. The current behavior is correct for >> Mac. Linux/Win should behave as you expect. Patches welcome. :) > > > Isn't

Re: [chromium-dev] scrolling a text area with shift-pgdn

This is a long-standing WebKit bug. The current behavior is correct for Mac. Linux/Win should behave as you expect. Patches welcome. :) On Thu, Nov 12, 2009 at 8:20 AM, John Tamplin wrote: > One thing that drives me nuts using GMail in Chrome compared to Firefox, is > the behavior of PgDn in a t

[chromium-dev] Re: How to log exceptions/console messages from shared worker context?

+chrome-devtools-team I think this is a general UI problem that needs to be solved for the inspector. There are increasingly more and more pages we have that don't have a page visible to the developer (sharedworkers, extensions background pages, etc.). I can't think of any good solutions off the t

[chromium-dev] revert now, ask questions later? WAS: Reverting a change, the fast way

On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain wrote: > This is really important to keep the tree green and open. The old saying > is "Revert now, think later"... If a change broke the build and the fix > would > take more than 1 or 2 minutes to be committed, or if the committer is not > answerin

[chromium-dev] Re: revising the output from run_webkit_tests

Can you give example outputs for the common cases? It would be easier to discuss those. On Fri, Oct 23, 2009 at 3:43 PM, Dirk Pranke wrote: > If you've never run run_webkit_tests to run the layout test > regression, or don't care about it, you can stop reading ... > > If you have run it, and you

[chromium-dev] Re: LTTF helping the GTTF make cycle times *minutes* faster

Tests/http/tests/navigation/onload-navigation-iframe-2.html LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html LayoutTests/http/tests/navigation/onload-navigation-iframe.html On Fri, Oct 16, 2009 at 2:42 PM, Jeremy Orlow wrote: > On Fri, Oct 16, 2009 at 2:34 PM, Ojan Vafa

[chromium-dev] Re: LTTF helping the GTTF make cycle times *minutes* faster

YUZO LayoutTests/fast/loader/local-JavaScript-from-local.html On Thu, Oct 15, 2009 at 6:38 PM, Ojan Vafai wrote: > There are a lot of tests that consistently (i.e. not flaky) timeout. They > eat up significant percentage (~10%!) of the cycle time for the test bots > (e.g., >1 minute on Win

[chromium-dev] LTTF helping the GTTF make cycle times *minutes* faster

There are a lot of tests that consistently (i.e. not flaky) timeout. They eat up significant percentage (~10%!) of the cycle time for the test bots (e.g., >1 minute on Windows release). If LTTF folk focus some effort on fixing these first, it would help all of us move forward faster as the bot cycl

[chromium-dev] Re: [announce] git-cl now has presubmit support.. read on to find out how to enable it!

On Thu, Oct 15, 2009 at 11:19 AM, Chase Phillips wrote: > On Thu, Oct 15, 2009 at 10:38 AM, Ojan Vafai wrote: > >> Replying off-list as requested... >> > Right! ;) > Doh. > However, my tests of gcl upload show they already have the same behavior >> here: gc

[chromium-dev] Re: layout test dashboard goofup

. At that point, doing backups seems more worthwhile. I'm happy to walk someone through how to make this happen. It really would not be a lot of work if you have a workable knowledge of Python and JS. Ojan On Wed, Oct 14, 2009 at 5:15 PM, Nicolas Sylvain wrote: > On Wed, Oct 14, 2009 at 4:5

[chromium-dev] Re: [announce] git-cl now has presubmit support.. read on to find out how to enable it!

Replying off-list as requested... Firstly, this is awesome! On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips wrote: > git-cl upload > Runs presubmit tests on upload, continues even if tests fail. > This latter part is different than the gcl version. Is that intentional? I don't have an o

[chromium-dev] Re: layout test dashboard goofup

On Wed, Oct 14, 2009 at 4:17 PM, Evan Martin wrote: > >> Sounds like we've got a volunteer! :D :D :D >> >> On Wed, Oct 14, 2009 at 4:15 PM, Jeremy Orlow >> wrote: >> > I assume we're going to start backing this data up from now on? >> > >&

[chromium-dev] layout test dashboard goofup

For those of you who rely on the layout test dashboard for identifying flakiness, my apologies. I accidentally checked in some test code (one number was wrong!) and clobbered all but 10 of the runs of data for each builder. There's no way to recover it. We'll just need to wait for enough runs for i

[chromium-dev] Re: [LTTF] Flaky tests and setTimeout

On Tue, Oct 13, 2009 at 3:50 PM, Andrew Scherkus wrote: > What's happening is loadstart fires and the video reloads which should > cause an abort event. For some reason load will occasionally fire after > loadstart, ending the test. > > I know we can patch the test, but I've been digging through

Re: Layout test flakiness WAS: [chromium-dev] Re: [LTTF][WebKit Gardening]: Keeping up with the weeds.

but continue to turn the tree red. This will provide more immediate feedback to people trying to green to tree as to whether tests are flaky or regressions. It would help with sheriffing/gardening without the other downsides. Ojan > On Tue, Oct 13, 2009 at 12:02 PM, Ojan Vafai wrote: &g

Layout test flakiness WAS: [chromium-dev] Re: [LTTF][WebKit Gardening]: Keeping up with the weeds.

We could rerun any unexpected fail/crash/timeout tests. If they pass the second time around, then the tree turns orange instead of red. This has come up many times, but we've never agreed on whether it's a good idea. Pros: -Easier to distinguish between flakiness and new failures -Tree will be much

[chromium-dev] Re: Stack trace wrapping when filing bugs

This seems like a Google Code bug to me. Pasting stacktraces should be a use-case Google Code cares about. Have you filed a bug with them? Ojan On Fri, Oct 9, 2009 at 11:17 AM, Jeremy Moskovich wrote: > crbug.com appears to wrap input to the width of it's textarea, that means > that if you paste

[chromium-dev] Re: [LTTF] Can someone look at some broad failure categories?

On Tue, Oct 6, 2009 at 1:49 PM, Peter Kasting wrote: > On Tue, Oct 6, 2009 at 1:44 PM, Andrew Scherkus wrote: > >> We're getting slightly different pixel results depending on the position >> of the sun. We have some WebKit patches underway that address our media >> rendering so it's safe to keep

[chromium-dev] Re: Shouldn't the Mac ignore the platform/win tests?

They are marked WONTFIX. We run them to ensure they don't crash. This looks like a bug in run_webkit_tests to me. For tests that are WONTFIX, we shouldn't care if the expected results are missing. Seems a bit silly to me that we run them at all though. I would be a fan of just skipping the platform

[chromium-dev] Re: Getting pixel tests running on the Mac

; maintenance burden and support ignoring problems. Situations where we're > willing to ignore one type of failure for an extended time should be rare. > I'd vote for keeping FAIL meaning image and/or text, and IMAGEFAIL for > temporary use meaning image-only. > - Pam > >

[chromium-dev] Re: Getting pixel tests running on the Mac

gt; > (And then post them to failblog if they're really embarassing.. J/K ;) > > On Wed, Sep 23, 2009 at 3:33 PM, Ojan Vafai wrote: > >> > >> +pam, tc, darin in case they disagree with what I'm saying here. > >> > >> Also a bunch of current

[chromium-dev] Re: Getting pixel tests running on the Mac

for image-only and text-only failures. Then we can gradually excise the FAIL lines from text_expectations. I think this would be a good permanent change, but I can see arguments to the contrary. Ojan On Wed, Sep 23, 2009 at 12:25 PM, Ojan Vafai wrote: > There is not. But adding it would be

[chromium-dev] Re: Getting pixel tests running on the Mac

There is not. But adding it would be easy. There's been mention of doing this for a while, but noone has made the effort to make it work. All you'd have to do is: -modify a few lines in TestExpectationsFile in src/webkit/tools/layout_tests/layout_package/test_expectations.py to add support for IMA

[chromium-dev] Re: [LTTF] Goals for the Layout Tests Task Force

On Tue, Sep 22, 2009 at 10:26 AM, Jeffrey Chang wrote: > > >- Fix all Windows layout tests: make test_expectations.txt only contain >items that we will never fix, features we have not yet implemented, or bugs >less than one week old that are a result of a recent WebKit merge. >- Se

[chromium-dev] Re: Layout tests can now be run on both XP and Vista

On Tue, Sep 15, 2009 at 2:24 PM, Dirk Pranke wrote: > Well, practically, there's very little difference between XP and Vista > (about 10 baselines). I see. Looking at your rebaseline checkin, it looks like it's entirely complex font tests as well. I think given that, it will be very rare that w

[chromium-dev] Re: Layout tests can now be run on both XP and Vista

On Tue, Sep 15, 2009 at 4:26 AM, Dirk Pranke wrote: > I have just landed a patch that enables us to run layout tests on > Vista as well as XP. > Thanks for doing this! Needing to run the tests on a 32bit XP machine sucks. I don't think we can call running the tests on Vista supported until the

[chromium-dev] Re: Are we now using Visual Studio 2008?

2009/9/14 Peter Kasting > 2009/9/14 Jungshik Shin (신정식, 申政湜) > >> I just got a z600 box and I was wondering about Webkit on Windows and VS >> 2008. According to the docs at webkit.org, VS 2008 is not supported, >> yet. I wonder how others deal with this issue. Do they have both 2005 and >> 2008

[chromium-dev] Re: [Chrome-team] understanding layout test flakiness

I'm including at the top concrete tasks people can take to help identify and reduce flakiness. Read below for more details. 1. Mark slow tests as SLOW and reduce the timeout on the bots to 2 seconds. 2. Look into the cause of the timeouts on HTTP tests, especially on Mac/Windows 3.

[chromium-dev] Re: WebKit Chromium Port

On Tue, Sep 8, 2009 at 6:43 PM, Jeremy Orlow wrote: > On Wed, Sep 9, 2009 at 10:18 AM, Adam Barth wrote: > >> > Or perhaps the >> > > Chromium port will just use JS bindings (no V8)? >> >> I think this is trickier than you might think. Also, it partially >> defeats the point of upstreaming our

[chromium-dev] Re: layout test dashboard

Done. On Tue, Sep 1, 2009 at 10:06 PM, Ojan Vafai wrote: > On Tue, Sep 1, 2009 at 6:42 PM, Peter Kasting wrote: > >> On Tue, Sep 1, 2009 at 5:15 PM, Ojan Vafai wrote: >> >>> I lied. Another update worth spamming about. >>> The dashboard now by default hid

[chromium-dev] Re: layout test dashboard

On Tue, Sep 1, 2009 at 6:42 PM, Peter Kasting wrote: > On Tue, Sep 1, 2009 at 5:15 PM, Ojan Vafai wrote: > >> I lied. Another update worth spamming about. >> The dashboard now by default hides both WONTFIX tests and tests that match >> their expectations. This way, th

[chromium-dev] Re: layout test dashboard

n On Wed, Aug 26, 2009 at 5:12 PM, Ojan Vafai wrote: > One final update. > >1. The bogus results on windows are gone. >2. BUG*** now actually links to the bug. >3. Hides WONTFIX tests by default, with a checkbox to show them. >4. Linux release bot is now listed (de

[chromium-dev] Re: [chromium-reviews] Re: WebKit deps roll 47797:47804

ce if we could list 2 bugs for one test. > >> The commented out one is NOT deadit's another type of failure that > is > >> currently overshadowed by the new type of failure. > >> > >> On Thu, Aug 27, 2009 at 10:57 AM, Ojan Vafai wrote: > >>

[chromium-dev] Re: layout test dashboard

d be useful to you. Ojan On Tue, Aug 25, 2009 at 10:15 AM, Ojan Vafai wrote: > One more thing (since people are asking), you can see all the platforms' > expectations for a test from the view for any builder. The ones that don't > apply to this builder are greyed

[chromium-dev] Re: layout test dashboard

t; builder. Ojan On Mon, Aug 24, 2009 at 6:42 PM, Ojan Vafai wrote: > > A first version of the layout test flakiness dashboard is up. > > http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html > > Some of the key features: > >-

[chromium-dev] layout test dashboard

A first version of the layout test flakiness dashboard is up. http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html Some of the key features: - updates roughly as quickly as the bots have run the tests (no post-processing, stdio parsing or crons)

[chromium-dev] Re: Handling layout test expectations for failing tests

On Mon, Aug 24, 2009 at 10:37 AM, Pam Greene wrote: > > On Sat, Aug 22, 2009 at 4:29 PM, Jeremy Orlow wrote: > >> On Sat, Aug 22, 2009 at 4:00 PM, Peter Kasting wrote: >> >>> On Fri, Aug 21, 2009 at 8:07 PM, Jeremy Orlow wrote: >>> >> There are different reasons for failing. A layout test could

[chromium-dev] Re: Handling layout test expectations for failing tests

On Fri, Aug 21, 2009 at 4:54 PM, Peter Kasting wrote: > On Fri, Aug 21, 2009 at 4:50 PM, Dirk Pranke wrote: > >> This is all good feedback, thanks! To clarify, though: what do you >> think the cost will be? Perhaps you are assuming things about how I >> would implement this that are different tha

[chromium-dev] Re: Stack traces on layout test crashes

On Mon, Aug 10, 2009 at 1:39 PM, Nicolas Sylvain wrote: > On Mon, Aug 10, 2009 at 10:35 AM, Jeremy Orlow wrote: > >> On Mon, Aug 10, 2009 at 9:59 AM, Ojan Vafai wrote: >> >>> On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow wrote: >>> >>>>

[chromium-dev] Re: Stack traces on layout test crashes

On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow wrote: > On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain wrote: > >> 2. The show stopper for any implementation of this feature is that the >> machines running the layout tests don't have the pdbs for test_shell. Since >> the binary is built on anothe

[chromium-dev] Re: Stack traces on layout test crashes

On Fri, Aug 7, 2009 at 8:45 PM, Jeremy Orlow wrote: > Has anyone ever looked into printing out stack traces when layout tests > crash? Of the couple layout test crashes I've investigated, I think most > could have been solved just by having a stack trace. I'm not really sure > what's involved o

[chromium-dev] Re: Git usage in chromium

On Thu, Aug 6, 2009 at 12:59 PM, Evan Martin wrote: > On Thu, Aug 6, 2009 at 9:55 AM, n179911 wrote: > > I read this about git usage in chromium: > > > > http://code.google.com/p/chromium/wiki/UsingGit > > After following the instructions in that document trunk/src is git and > everything else (p

[chromium-dev] Re: Copy URL as plain text instead of HTML

This is kind of off topic, but should we consider adding a copy/cut-as-plain-text keyboard shortcut (ctrl+shift+c/x). That would be nicely symmetrical with ctrl+shift+v for paste-as-plain-text. Ojan On Fri, Jul 31, 2009 at 4:57 PM, Scott Violet wrote: > > I just happen to be looking at clipboard

[chromium-dev] Re: Duplicate expectations?

You are, in fact, on crack. :) It was never a presubmit script. We just talked about making it one a lot. On Tue, Jul 28, 2009 at 3:52 PM, Mike Pinkerton wrote: > I'm almost positive we made it so because we had so much trouble when > we were bringing up the mac and linux ports. I could be on cra

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

tructions on how to use > the change descriptions every time I make a CL. I think what I'm proposing > makes it obvious enough for newcomers while optimizing for people who submit > a lot of CLs. > > J > > On Wed, Jul 22, 2009 at 1:43 PM, Ojan Vafai wrote: > >> I&

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

this text: DETAILED_DESCRIPTION_HERE BUG=http://bugs.chromium.org/BUG_NUMBER_HERE TEST=required RELEASE_NOTES=optional On Wed, Jul 22, 2009 at 1:28 PM, Jeremy Orlow wrote: > On Wed, Jul 22, 2009 at 1:22 PM, Peter Kasting wrote: > >> On Wed, Jul 22, 2009 at 1:17 PM, Ojan Vafai wrote:

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 12:26 PM, Jeremy Orlow wrote: > On Wed, Jul 22, 2009 at 11:57 AM, Ojan Vafai wrote: > >> This is an understatement. We really do a poor job with commit >> descriptions. There is a lot to be gained by having better commit >> descriptions. We can l

[chromium-dev] better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 10:07 AM, Darin Fisher wrote: > On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley wrote: > >> * By having the ChangeLog in the review, reviewers can critique it. >> > >> Many of our commit messages are little brief. Some are far too brief. >> But, the commit message should m

[chromium-dev] Re: Mozilla design challenge

There are heuristics we can come up with that are fairly safe. They might be too conservative to be useful though. For example, it should almost always be safe to kill a page that:-has no unload/beforeunload listeners registered -has had no user-interaction that caused JS to execute -has had no use

[chromium-dev] Re: How to exclude src/third_party/WebKit/LayoutTests when checkout chromium source code

They'll eventually be moved into upstream webkit's repository, at which point they'll be in third_party/WebKit. On Thu, Jul 16, 2009 at 9:43 AM, Jeremy Orlow wrote: > Maybe those should be moved out of the source tree (into deps) so that they > can be excluded? > > > On Thu, Jul 16, 2009 at 9:23

[chromium-dev] Re: Buildbot performance issue.

On Tue, Jul 14, 2009 at 2:35 PM, Nicolas Sylvain wrote: > On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin wrote: > >> On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvain >> wrote: >> It seems to me a caching layer that only ever hit the "backend" every >> > ten seconds would allow it ten seconds to gri

[chromium-dev] Re: Buildbot performance issue.

On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvain wrote: > Q3: What kind of auto-refresh do we need? > > We used to be at 60 secs for a long time, and I changed it a couple of > weeks ago to 90 secs. > No one complained, so I guess this is good. Should we go even higher than > that? > Why do w

[chromium-dev] Re: Rewrite of DOMUI l10n strings

2009/7/9 Rafael Weinstein > However, because some of our existing pages use JSTemplate both for > injecting strings and for doing dynamic composition, the jst directives can > colide. Consider the following: > > >Download: jscontent="url"> http://www.some.com/.. . >

[chromium-dev] Re: WebKit Sheriffing Documentation Update

For the layout tests steps, why do you we need to build test_shell locally, rebaseline and then add the other platforms to tests_fixable? Can't we just use the rebaseline tool and point it at the integration bots? Currently, you can point the tool at a specific builder. Maybe we could add a --integ

[chromium-dev] Re: how to judge layouttests' running result?

This is not a pass. Specifically "Regressions: Unexpected failures" lists the failures. Other times, you'll see "Regressions: Unexpected *" where * is crash, timeout, failures, etc. Also, it should have popped up a window with the results just for the failing tests. Ojan 2009/6/25 David Jones >

[chromium-dev] Re: layout test can't run

What Windows are you on? Vista cannot run some of the layout tests. There is a flag you can pass to run_webkit_tests to get it to ignore the system dependencies check. I don't remember the name off the top of my head. To find it run: run_webkit_tests.sh --help The flag will let you run the tests o

[chromium-dev] Re: Pixel layout tests and checksums

This isn't the best, but it would be easy to add a flag to run-webkit-tests that told it to always do the pixel comparison even if the checksums matched. Ojan On Mon, Jun 22, 2009 at 10:55 AM, Evan Martin wrote: > > Just so I'm not all negative, my suggestions after consulting with Tony: > > 1)

[chromium-dev] Re: Resurrecting the JSC build.

We discontinued it because we had a ton of files forked and it was getting to be a lot of work to maintain. PROS -Can more easily identify v8 layout test failures -Can ensure that all the USE(JSC) blocks are actually about the JS engine instead of just Chromium/Safari-specific code. -Good for ident

[chromium-dev] Re: Developing Chrome using tip-of-tree WebKit

On Tue, May 12, 2009 at 3:16 AM, Darin Fisher wrote: > Then, create a .gclient file like so: > > solutions = [ > { "name" : "src", >"url" : "http://src.chromium.org/svn/trunk/src";, >"custom_deps" : { > 'src/third_party/WebKit': ' > http://svn.webkit.org/repository/webkit/trunk', >

[chromium-dev] Re: build error

ame thing (failure in v8::internal::NativesCollection). > > Thanks, > > Stephen > > On Thu, May 7, 2009 at 11:49 PM, Ojan Vafai wrote: > >> I've been getting the following build error for the past couple days on >> Windows. It happens if I use Incredibuild or VS.

[chromium-dev] Re: build error

? > > On Thu, May 7, 2009 at 8:49 PM, Ojan Vafai wrote: > >> I've been getting the following build error for the past couple days on >> Windows. It happens if I use Incredibuild or VS. It happens on a totally >> fresh checkout. Any one have any ideas as to what cou

[chromium-dev] build error

I've been getting the following build error for the past couple days on Windows. It happens if I use Incredibuild or VS. It happens on a totally fresh checkout. Any one have any ideas as to what could be causing this? 9>-- Build started: Project: mksnapshot, Configuration: Debug Win32 -- 9

[chromium-dev] FYI: DEFER no longer means anything

I just committed a change that removes defer from text_expectations.txt. That means that the number of failing tests the bot reports is the total number of webkit tests that we'll ever want to fix (e.g. win-release went from 141 fixable to 768 fixable). In order to know which of those tests need to

[chromium-dev] Re: Unpacking Extensions and the Sandbox

An advantage of the utility process is that it's not tied to the lifetime of the tab, so we don't have to deal with edge cases like when the user closes a tab that's mid-installing an extension. Ojan On Fri, May 1, 2009 at 10:42 AM, Adam Barth wrote: > > I think we should go with the utility pro

[chromium-dev] Re: No more commits to third_party/WebKit

This should still work fine. One person can lock the whole directory, then people who need to commit unforkage can lock the specific files they need to unfork using --force. That said, the only forkage that happens these days is when doing a webkit merge. What should the merger do if they find them

[chromium-dev] Re: UI test improvement

On Thu, Apr 16, 2009 at 3:22 PM, Huan Ren wrote: > > I am trying to improve the UI automation framework with the goal of > reducing disabled UI test from 42 to 10 and running time (xp release) > from 400s to 200s. We got a ~2x performance improvement by running the webkit tests in parallel on du

[chromium-dev] Re: Creating bugs from test_expectations.txt

on running the script later today with the most recent >> version of test_expectations.txt -- there will be 200+ new bugs. Let me >> know if I should hold off on doing so. Ojan, I'll send you the review for >> test_expecations.txt. >> >> Regards, >> Gl

[chromium-dev] Re: Creating bugs from test_expectations.txt

CL ready, if anyone with Java readability would be willing > to do a review, please let me know. > more inline... > > On Fri, Apr 10, 2009 at 2:07 PM, Pam Greene wrote: > >> >> >> On Thu, Apr 9, 2009 at 6:49 PM, Ojan Vafai wrote: >> >>> At a qui

[chromium-dev] Re: Creating bugs from test_expectations.txt

At a quick glance, this looks great. I didn't look over every bug, but the ones I did look at look good. It would be great to check in a version of this script that we could run when a number of tests fail (e.g. when doing a bad webkit merge). That way, we can add them all to the local test_expecta

[chromium-dev] help make running webkit tests fast

There's a ton of work that to be done to make running webkit tests considerably faster. I think we could still get >2x faster. I'm doing some of it, but could definitely use some help. I've compiled a list of bugs for the tasks that need doing (gave them the label WebkitTestsPerf). Please take a lo

[chromium-dev] Re: release builders now run webkit tests in parallel

On Thu, Apr 9, 2009 at 9:06 AM, Pam Greene wrote: > On that note, though, it would be amazing if someone wanted to figure out > the interdependencies. We have three run_webkit_tests otpions available to > help: --randomize-order, which runs the tests in a random > order;--run-singly, which launc

[chromium-dev] Re: release builders now run webkit tests in parallel

2009 at 12:06 PM, Pam Greene wrote: > >> On Mon, Apr 6, 2009 at 6:57 PM, David Levin wrote: >> >>> >>> >>> On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai wrote: >>> >>>> run_webkit_test.sh now runs cpus+1 test_shells for Release builds.

[chromium-dev] Re: release builders now run webkit tests in parallel

On Mon, Apr 6, 2009 at 6:57 PM, David Levin wrote: > Release tests on a dual core now take about half the time they used to. >> There's still a lot of room for improvement and I'm a bit burnt out on this >> stuff, so if anyone is willing to help that would be much appreciated. Here >> are the rem

[chromium-dev] release builders now run webkit tests in parallel

run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please keep an eye out over the next couple days for test flakyness that may have resulted from this. Release tests on a dual core now take about half the time they used to. There's still a lot of room for improvement and I'm a bit

Re: IMPORTANT: Re: [chromium-dev] Re: layout tests and bug triaging

; we pass. Instead, we'll > have to take one number from that report and one number (searching on > priority/milestone) from the code tracker. > > If the people who do that regularly (Jon?) are happy with that, then I have > no problem with it. > > - Pam > > > On Thu,

Re: IMPORTANT: Re: [chromium-dev] Re: layout tests and bug triaging

we implement FrobozzClient". (So any script that does this > should ask for a description, not just file a bare bug.) > > - Pam > > > On Wed, Mar 25, 2009 at 4:00 PM, Ojan Vafai wrote: > >> Just want to make sure everyone sees this. Please voice yours

IMPORTANT: Re: [chromium-dev] Re: layout tests and bug triaging

It makes for a more consistent way of >> following up >> >> on our progress... Even if the end result is just a re-baseline, we >> also >> >> gain the link to the bug from the committed change list (and vice >> versa). >> >> And if we want some

[chromium-dev] recent changes to webkit test list expectations

tests_ignored.txt and tests_fixable.txt no longer exist. They were merged into a single file: src/webkit/tools/layout_tests/test_expectations.txt. All the files that were previously ignored now have the WONTFIX metadata applied to them. WONTFIX means that we never intend to pass the test. WONTFIX W

[chromium-dev] Re: layout tests and bug triaging

ge on the >> chromium-status appEngine that would read from the latest version of the >> test list file, and maybe some details (e.g., owner) from the issue >> tracker... Maybe... ;-) >> >> BYE >> MAD >> On Tue, Mar 24, 2009 at 2:57 PM, Ojan Vafai wrote:

[chromium-dev] layout tests and bug triaging

I'm going about adding support to the webkit test list for BUGx metadata and replacing DEFER with P0/P1/P2/P3. I've come to the conclusion that we need to better understand our desired workflow for dealing with failing layout tests. *TEST OWNERSHIP:* Firstly, can we move away from using the spr

[chromium-dev] Re: src/WEBKIT_MERGE_REVISION

. > > :DG< > > On Mon, Mar 23, 2009 at 10:03 PM, Eric Seidel > wrote: > > Kill it (or I can, as part of the merge tomorrow)... so long as the merge > > instructions are up to date. > > > > On Mon, Mar 23, 2009 at 5:46 PM, Ojan Vafai wrote: > >

[chromium-dev] src/WEBKIT_MERGE_REVISION

I think this file is basically useless at this point. All the information in it is encoding in src/DEPS (it now has a webkit_revision VAR). Any objection to getting rid of this file? It's one fewer thing for the merger to keep track of. I'll delete the file tomorrow if I hear no objections. Ojan -

[chromium-dev] Re: Flaky http tests on the mac

s exception.. LayoutTests/http/othertest.html = CRASH NEVER_FIX : LayoutTests/http/othertest.html = FAIL Ojan On Fri, Mar 13, 2009 at 10:52 AM, Ojan Vafai wrote: > Being deputy this week, I've seen a ton of flaky tests on the mac. The vast > majority of these tests have been the http te

[chromium-dev] Re: SVG tests and sanity

I think this is fine, but we should stay on top of new svg regressions from here forward. Ojan On Fri, Mar 13, 2009 at 11:48 AM, Marc-Antoine Ruel wrote: > > Stress reliever. But I won't have fixed any layout tests. :( > > > On Fri, Mar 13, 2009 at 2:28 PM, Scott Violet wrote: >> >> YES! DEFER

  1   2   >