Re: [chromium-dev] Re: updates to tech talks page: added link to "Exploring Chrome Internals" slide deck, etc

[David Levin]

On Wed, Jan 13, 2010 at 3:55 PM, Chase Phillips  wrote:

> On Wed, Jan 13, 2010 at 14:50, Chase Phillips  wrote:
>
>> Darin's June 2, 2009 Google I/O "Exploring Chrome Internals" presentation
>> slide deck is now available from
>> http://sites.google.com/a/chromium.org/dev/developers/tech-talk-videos.
>>
>> Along with that, I gave the page a facelift.  Will be easier to change and
>> include extra info about talks going forward.
>>
>
> With the help of Peter Kasting and Eric Roman (thanks!), I catalogued as
> complete a list of inaccuracies between what the slides describe and the
> current Chrome version:
>
> Slide 18: With new painting and scrolling optimizations, this process is
> more complex than what's shown
> Slide 23: Chrome 3 released in 2009, uses a WebKit version not yet in any
> current Safari release
> Slide 24: 6 WebKit reviewers @chromium.org, 37 WebKit committers @
> chromium.org, WebKit API is done
>

 6 webkit reviewers with @chromium.org (but 8 if you include e...@webkit.organd
aba...@webkit.org.)


> Slide 25: OWP Local and session storage: completed
> Slide 27: Networking feature parity and sparse caching: completed
>
> Please update with any corrections and other differences if you see them.
>
> Chase
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] layout-test outputs and spell-checker

[David Levin]

On Wed, Dec 16, 2009 at 4:25 AM, Jeremy Moskovich wrote:

> Hi Horonori,
>
> Thanks for taking a look at this!!
>
> What kinds of differences are you seeing without the new spellchecker
> class?
>
> The only notable difference seems to be that the fonts are slightly
> different vs. the expected output.
>

The fonts appear bolded in this case (to me).


>
> Where is the expected output coming from?  What OS version are you running
> this on?
>
> btw. The scrollbar diffs are to expected as we draw scrollbars differently
> in Chrome than Safari does.
>
> Best regards,
> Jeremy
>
> 2009/12/16 Hironori Bono (坊野 博典) 
>
> Greetings chromium-developers,
>>
>> Sorry for my beginner's question in advance.
>> To fix a long-lasting issues: Issue 11577 (*1) and Issue 23497 (*2), I
>> have implemented a MockSpellcheck class (*3), which is a mock
>> implementation of our spell-checker used for layout tests. Even though
>> this change can fix most layout-test failures listed in Issue 23497,
>> there are a layout test that fails on an unknown reason,
>> "editing/selection/unrendered-002.html".
>> To run such tests on my Mac, our test_shell outputs very similar
>> images as the expected one but actually different ones as shown in the
>> attached pictures. Would it be possible to give me your thoughts about
>> why our test_shell cannot create the expected image for this case?
>>
>> (*1) http://crbug.com/11577
>> (*2) http://crbug.com/23497
>> (*3) http://codereview.chromium.org/493003/show
>>
>> Best regards,
>>
>> Hironori Bono
>> E-mail: hb...@chromium.org
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>
>
>  --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

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

[David Levin]

On Mon, Dec 14, 2009 at 10:24 AM, Scott Hess  wrote:

> Additionally, keep in mind that obscure bugs may take longer to find
> an owner than the buildbots keep logs.  So a bug like "Disable to
> green the buildbots, " is not sufficient, include enough info so
> that someone can figure out WHY you're disabling things.
>
> Also, last time I was looking through some valgrind suppressions, I
> found that often enough the new suppression NEVER fired.  I know this
> is asking a lot, but if you throw down some new suppressions during
> your tour of duty, it would be great if you check back in a few days
> or a week later and if they aren't being applied, back them out (maybe
> with a current sheriff as reviewer in case they pop back up).
> [valgrind prints out the list of suppressions which fired at the end
> of the run.]
>


Of course, it would be awesome if thus was automated in some way like the
flaky layout tests. You get a list of tests that have been passing for the
last 75 runs which are in test_expectations (because some suppressions
aren't hit every time). If there were something similar for valgrind (e.g.
"suppressions not used in the last 75 runs"), it would be great.

dave


>
> -scott
>
>
> On Mon, Dec 14, 2009 at 10:00 AM, John Abd-El-Malek 
> wrote:
> > (this topic has been on my mind a lot, so here's my vent :) )
> > I think we shouldn't allow any test to be disabled without a bug to track
> it
> > that includes an initially assigned owner. This shouldn't
> > I've seen it happen too often that a test gets disabled to quickly turn
> the
> > tree green, and it stays disabled for a long time without anyone
> noticing.
> >  This destroys the whole point of tests, since it's trivial to keep a
> tree
> > green by disabling each test when it fails.  It's also a large burden to
> > expect that people monitor checkins to files they're familiar with and
> > create bugs when they find a disabled test.  It's harder to enforce this,
> > and it's also unclear who should be doing this when multiple people touch
> an
> > area.
> > Filing a bug and looking at the annotations on viewvc to pick an initial
> > owner shouldn't take more than a minute or two so I don't think it's a
> large
> > burden.
> > On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson 
> wrote:
> >>
> >> I spent a few hours last week and this weekend trying to untangle the
> mess
> >> that was the worker ui_tests. The problem is that the tests have been
> >> sporadically flakey due to various causes, and so various sheriffs/good
> >> samaritans have disabled them to keep the trees green. Some of the tests
> >> were disabled due to failing under valgrind, but now that we have a way
> to
> >> disable tests specifically for valgrind and some of the worker bugs have
> >> been fixed upstream I figured it was a good time to clean house a bit
> and
> >> re-enable some of the tests.
> >> I found when I was going through the worker_uitest file that it was hard
> >> to figure out why a given test was disabled, so it was unclear whether
> it
> >> was safe to re-enable them - some of the tests had comments pointing at
> a
> >> tracking bug, but some of them didn't, and it was a pain to track the
> root
> >> cause especially since the specific lines of code had sometimes been
> touched
> >> multiple times (adding new platforms to disable, etc).
> >> Anyhow, what's our best practices for disabling tests? I think ideally
> >> we'd always log a tracking bug and add a comment, akin to what we do in
> the
> >> test_expectations file for layout tests. This might be too much of a
> burden
> >> on sheriffs, so an alternative is for people who are working on various
> >> areas (like workers) track checkins to the associated files and add some
> >> documentation after the fact. Or we can just live with the SVN logs, in
> >> which case I need to get better about figuring out how to track through
> the
> >> SVN/git history of the various files :)
> >>
> >> -atw
> >>
> >> --
> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> View archives, change email options, or unsubscribe:
> >> http://groups.google.com/group/chromium-dev
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] revised output for run_webkit_tests

[David Levin]

On Thu, Dec 10, 2009 at 10:57 PM, Dirk Pranke  wrote:

> We could do this, but we'd have to add logic to track when directories
> were "done", and arbitrarily delay printing results about "other"
> directories (hence delaying and serializing results). This might end

up causing weirdly irregular bursts of output.


The irregular bursts of output isn't that bad. (I had a version of
run-webkit-test that did this.  Unfortunately, perl is not a fun language
for me at least, and I have to admit that the perl code I had would have
been hard to maintain/fragile.)

Worst case, since we
> intentionally run the "http" tests first, and they're the long pole in
> the run, this might delay printing all the other directories until
> near the end.


Not a big deal either. My version did this as well. (I started this behavior
in my webkit version and talked to Ojan about doing it.)


> I'm not sure what the real benefit of this would be.
>

The benefit is working in a community and understanding how they do things
and adapting to that as opposed to trying to push something very different
on them.


> (A) Have you looked at the new output yet?


> (B) Is getting output by directory really that useful?
>

I understood your description. Having run the webkit version, I much prefer
it due to knowing when certain directories are done and knowing what test(s)
failed in those directories as the test goes along (even in the parallel
version where the failures may be slightly delayed).

The output by directory also adapts better to the buildbot output instead of
the huge test-by-test list that chromium buildbots have (which takes a while
to download when you click the link for stdio).

dave


> -- Dirk
>
> On Thu, Dec 10, 2009 at 10:10 PM, David Levin  wrote:
> > Actually, you can have a similar output even with the multi-threading.
> > You can display the results for one only directory (even though multiple
> > directories are being processed at the same time) and when that directory
> is
> > done, display the results for the next directory until it is done,
> etc. The
> > ordering of the directories may be different but the output is very
> similar
> > to what they have now.
> > The effect is quite satisfying and clear.
> > dave
> > On Thu, Dec 10, 2009 at 10:04 PM, Dirk Pranke 
> wrote:
> >>
> >> Yes, I did consider that. The fatal flaw in that plan is that the
> >> webkit test script is single-threaded and runs through the tests in
> >> order. Ours doesn't, and so we can't easily guarantee the same sort of
> >> output they have. Eric and I will probably work through this as we
> >> upstream the code. I'm actually hoping to get them to adopt my output,
> >> but we'll see.
> >>
> >> -- Dirk
> >>
> >> On Thu, Dec 10, 2009 at 7:45 PM, David Levin 
> wrote:
> >> > Have you considered making the output closer to that of WebKit's
> >> > run-webkit-tests?
> >> > It seems that would ease the hopeful transition to this version
> >> > upstream.
> >> > dave
> >> > On Thu, Dec 10, 2009 at 7:23 PM, Dirk Pranke 
> >> > wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> If you never run the webkit layout tests, you can stop reading.
> >> >>
> >> >> Otherwise, earlier today I checked in a patch that should make the
> >> >> output much less verbose in the normal case. From the CL:
> >> >>
> >> >> First, a number of log messages have had their levels changed (mostly
> >> >> to
> >> >> make them quieter).
> >> >>
> >> >> Second, the script outputs a "meter" that shows progress through the
> >> >> test run, which is a one line summary of where it's at current
> >> >> (e.g. "parsing expectations", "gathering files". During the actual
> test
> >> >> execution, the meter displays "%d tests completed as expected, %d
> >> >> didn't,
> >> >> %d remain". The meter uses carriage returns but no linefeeds, so the
> >> >> output
> >> >> is overwritten as it progresses. The meter is disabled if --verbose
> is
> >> >> specified, to avoid unnecessary confusion.
> >> >>
> >> >> Third, I removed the --find-baselines option. I think I was the only
> >> >> one
> >> >> using it, and --sources is good enough (but added the baseline for
> >> >> the checksum as well as t

Re: [chromium-dev] revised output for run_webkit_tests

[David Levin]

Actually, you can have a similar output even with the multi-threading.

You can display the results for one only directory (even though multiple
directories are being processed at the same time) and when that directory is
done, display the results for the next directory until it is done, etc. The
ordering of the directories may be different but the output is very similar
to what they have now.

The effect is quite satisfying and clear.

dave

On Thu, Dec 10, 2009 at 10:04 PM, Dirk Pranke  wrote:

> Yes, I did consider that. The fatal flaw in that plan is that the
> webkit test script is single-threaded and runs through the tests in
> order. Ours doesn't, and so we can't easily guarantee the same sort of
> output they have. Eric and I will probably work through this as we
> upstream the code. I'm actually hoping to get them to adopt my output,
> but we'll see.
>
> -- Dirk
>
> On Thu, Dec 10, 2009 at 7:45 PM, David Levin  wrote:
> > Have you considered making the output closer to that of WebKit's
> > run-webkit-tests?
> > It seems that would ease the hopeful transition to this version upstream.
> > dave
> > On Thu, Dec 10, 2009 at 7:23 PM, Dirk Pranke 
> wrote:
> >>
> >> Hi all,
> >>
> >> If you never run the webkit layout tests, you can stop reading.
> >>
> >> Otherwise, earlier today I checked in a patch that should make the
> >> output much less verbose in the normal case. From the CL:
> >>
> >> First, a number of log messages have had their levels changed (mostly to
> >> make them quieter).
> >>
> >> Second, the script outputs a "meter" that shows progress through the
> >> test run, which is a one line summary of where it's at current
> >> (e.g. "parsing expectations", "gathering files". During the actual test
> >> execution, the meter displays "%d tests completed as expected, %d
> didn't,
> >> %d remain". The meter uses carriage returns but no linefeeds, so the
> >> output
> >> is overwritten as it progresses. The meter is disabled if --verbose is
> >> specified, to avoid unnecessary confusion.
> >>
> >> Third, I removed the --find-baselines option. I think I was the only one
> >> using it, and --sources is good enough (but added the baseline for
> >> the checksum as well as the .png when using --sources).
> >>
> >> Fourth, there is a new "--log" option that can be used to provide finer
> >> granularity of logging. It accepts a comma-separated list of options,
> >> like:
> >> --log 'actual,expected,timing':
> >>
> >>  "actual": the actual test results (# of failures by type and timeline)
> >>  "config": the test settings (results dir, platform, etc.)
> >>  "expected": the results we expected by type and timeline
> >>  "timing": test timing results (slow files, total execution, etc.)
> >>
> >> All of this information is logged at the logging.info level (if the
> >> appropriate option is enabled).
> >>
> >> Using the --verbose switch will cause all of options to be logged, as
> well
> >> as the normal verbose output.  In addition, the verbose output will
> >> disable
> >> the meter (as mentioned above). Note that the "actual" results will be
> >> logged
> >> to stdout, not stderr, for compatibility with the buildbot log parser.
> >>
> >> Finally, the list of unexpected results (if any) will be logged to
> stdout,
> >> along with a one-line summary of the test run.
> >>
> >> The net result is that when run with no command line options (and when
> no
> >> tests fail), only one line of output will be produced.
> >>
> >> Feedback / problems / questions to me.
> >>
> >> Pam, sorry for making all of your examples in your tech talk
> >> immediately out of date :)
> >>
> >> -- Dirk
> >>
> >> --
> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> View archives, change email options, or unsubscribe:
> >>http://groups.google.com/group/chromium-dev
> >
> >
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] revised output for run_webkit_tests

[David Levin]

Have you considered making the output closer to that of WebKit's
run-webkit-tests?

It seems that would ease the hopeful transition to this version upstream.

dave

On Thu, Dec 10, 2009 at 7:23 PM, Dirk Pranke  wrote:

> Hi all,
>
> If you never run the webkit layout tests, you can stop reading.
>
> Otherwise, earlier today I checked in a patch that should make the
> output much less verbose in the normal case. From the CL:
>
> First, a number of log messages have had their levels changed (mostly to
> make them quieter).
>
> Second, the script outputs a "meter" that shows progress through the
> test run, which is a one line summary of where it's at current
> (e.g. "parsing expectations", "gathering files". During the actual test
> execution, the meter displays "%d tests completed as expected, %d didn't,
> %d remain". The meter uses carriage returns but no linefeeds, so the output
> is overwritten as it progresses. The meter is disabled if --verbose is
> specified, to avoid unnecessary confusion.
>
> Third, I removed the --find-baselines option. I think I was the only one
> using it, and --sources is good enough (but added the baseline for
> the checksum as well as the .png when using --sources).
>
> Fourth, there is a new "--log" option that can be used to provide finer
> granularity of logging. It accepts a comma-separated list of options, like:
> --log 'actual,expected,timing':
>
>  "actual": the actual test results (# of failures by type and timeline)
>  "config": the test settings (results dir, platform, etc.)
>  "expected": the results we expected by type and timeline
>  "timing": test timing results (slow files, total execution, etc.)
>
> All of this information is logged at the logging.info level (if the
> appropriate option is enabled).
>
> Using the --verbose switch will cause all of options to be logged, as well
> as the normal verbose output.  In addition, the verbose output will disable
> the meter (as mentioned above). Note that the "actual" results will be
> logged
> to stdout, not stderr, for compatibility with the buildbot log parser.
>
> Finally, the list of unexpected results (if any) will be logged to stdout,
> along with a one-line summary of the test run.
>
> The net result is that when run with no command line options (and when no
> tests fail), only one line of output will be produced.
>
> Feedback / problems / questions to me.
>
> Pam, sorry for making all of your examples in your tech talk
> immediately out of date :)
>
> -- Dirk
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Re: buildbot failure in Chromium on Chromium Linux x64, revision 34161

[David Sehr]

Apologies to all.  This was caused by my checkin, which is now backed out.

On Wed, Dec 9, 2009 at 9:33 AM,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "compile" on "Chromium Linux x64"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux%20x64/builds/3337
>
> Revision: 34159, 34161
> Blame list: cmas...@google.com,s...@google.com
>
>  Chromium Linux x64
> Build 
> 3337
>   update
> scripts
> stdio
> update
> stdio
> compile
> failed
> stdio
>
> Changed by: *cmas...@google.com*
> Changed at: *Wed 09 Dec 2009 09:09:23*
> Branch: *src*
> Revision: 
> *34159*
> Changed files:
>
>- *views/screen_gtk.cc*
>
> Comments:
>
> Uses X mechanisms to get the screen size in the event that there's no window 
> manager to query.
> Review URL: http://codereview.chromium.org/460134
>
> Properties:
>
>
>  Changed by: *s...@google.com*
> Changed at: *Wed 09 Dec 2009 09:19:23*
> Branch: *src*
> Revision: 
> *34161*
> Changed files:
>
>- *build/all.gyp*
>- *build/common.gypi*
>- *chrome/browser/renderer_host/browser_render_process_host.cc*
>- *chrome/chrome_renderer.gypi*
>- *chrome/common/chrome_switches.cc*
>- *chrome/common/chrome_switches.h*
>- *chrome/renderer/render_view.cc*
>- *webkit/glue/plugins/npapi_extension_thunk.cc*
>- *webkit/glue/plugins/plugin_host.cc*
>- *webkit/glue/webplugin.h*
>- *webkit/glue/webplugin_impl.cc*
>- *webkit/tools/pepper_test_plugin/README*
>- *webkit/tools/pepper_test_plugin/event_handler.cc*
>- *webkit/tools/pepper_test_plugin/pepper_test_plugin.gyp*
>
> Comments:
>
> Enable Pepper support by default, including building the test plugin.
> This is needed because the NaCl plugin code that runs in the renderer
> needs to use Pepper APIs all the time, and NaCl support has been enabled
> by default for several months now.  To cause an untrusted Pepper plugin
> to run in the renderer one needs to specify the --internal-pepper flag.
> I have also removed the enable_pepper flag from gyp.  As the build of the
> GPU process was tied to this flag, I have renamed the flag to enable_gpu.
> TEST=none
> BUG=none
>
> Review URL: http://codereview.chromium.org/464074
>
> Properties:
>
>
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure

[David Levin]

That is excellent! I didn't know there was such a thing.

Thanks,
Dave


On Tue, Dec 1, 2009 at 4:09 PM, oshima  wrote:

> # Re-sending b/c gmail didn't use my account properly. Sorry if you get
> this twice.
>
> On Tue, Dec 1, 2009 at 3:53 PM, David Levin  wrote:
>
>>
>>
>> On Tue, Dec 1, 2009 at 2:30 PM, oshima  wrote:
>>
>>> Looks like there are more tests that failing in valgrind test.
>>>
>>> shard=1 id=1513
>>> [  FAILED  ] WorkerTest.MultipleWorkers (103254 ms)
>>> [  FAILED  ] NewTabUITest.ChromeInternalLoadsNTP (74002 ms)
>>> [  FAILED  ] ChromeMainTest.AppLaunch (36539 ms)
>>> shard=2 id=1916
>>> [  FAILED  ] WorkerTest.IncognitoSharedWorkers (181154 ms)
>>> [  FAILED  ] SessionHistoryTest.FLAKY_LocationReplace (48297 ms)
>>> shard=3 id=1761
>>> [  FAILED  ] WorkerTest.SharedWorkerFastLayoutTests (731911 ms)
>>> [  FAILED  ] AutomationProxyTest.NavigateToURLWithTimeout1 (42516 ms)
>>> shard=4 id=2075
>>> [  FAILED  ] WorkerTest.WorkerHttpLayoutTests (119981 ms)
>>> [  FAILED  ] AutomationProxyTest.NavigateToURLWithTimeout2 (36359 ms)
>>> [  FAILED  ] UnloadTest.CrossSiteInfiniteBeforeUnloadSync (342050 ms)
>>> [  FAILED  ] MetricsServiceTest.CrashRenderers (49324 ms)
>>>
>>> This is not good. Is there any issue if we make a valgrind test fail when
>>> the test itself fails?
>>> If not, I'd suggest that we exclude them in ui_tetsts.gtext.txt for now
>>> (I'll file bugs)
>>> and change the test script so that a valgrind test fails when the test
>>> itself tails.
>>> Any opinion?
>>>
>>>
>> My quick read of this makes it sounds like you're planning to
>> disable various tests (like WorkerTests which can easily get broken due to
>> webkit changes) so that *they don't run at all* simply because valgrind
>> can't seem to run it.  Please don't do that.
>>
>> No. This is just for valgrind tests.
>
>
>> If you're going to do changes to scripts and such, maybe you can change it
>> so that valgrind has some additional skip list.
>>
>>
> Yes that's what I'm going to do. See
> chrome/test/data/valgrind/ui_tests.gtest.txt
>
> - oshima
>
>
>> Thanks,
>> Dave
>>
>> - oshima
>>> On Fri, Nov 20, 2009 at 12:25 PM, Mitsuru Oshima wrote:
>>>
>>>> Hi,
>>>>
>>>> I noticed, while working on enabling valgrind test on linux/views, that
>>>> some of WorkerTest of ui tests in Linux Tests (valgrind) buildbot
>>>> are failing due to mmap failure.I tested locally with valgrind I
>>>> built using the script under tools/valgrind (with regular ld, but not 
>>>> gold),
>>>> and I got the same/similar mmap errors. I did quick search on bug db,
>>>> but couldn't find it. I'm going to file a bug, but does anyone know about
>>>> this problem?
>>>>
>>>> - oshima
>>>>
>>>> [==] Running 37 tests from 23 test cases.
>>>> [--] Global test environment set-up.
>>>> [--] 2 tests from WorkerTest
>>>> [ RUN ] WorkerTest.SingleWorker
>>>> [8072:8072:1120/090807:5253075177881:INFO:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/test/ui/ui_test.cc(1126)]
>>>> BROWSER_WRAPPER was set, prefixing command_line with
>>>> /b/slave/chromium-rel-linux-valgrind-tests-1/build/valgrind.tmp/browser_wrapper.ohLiPE
>>>> valgrind: mmap(0x3800, 1871872) failed in UME with error 22 (Invalid
>>>> argument).
>>>> valgrind: this can be caused by executables with very large text, data
>>>> or bss segments.
>>>> /b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/worker/worker_uitest.cc:28:
>>>> Failure
>>>> Value of: value.c_str()
>>>> Actual: ""
>>>> Expected: kTestCompleteSuccess
>>>> Which is: "OK"
>>>> [8078:8078:5253178758444:ERROR:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/browser/automation/automation_provider.cc(957)]
>>>> AutomationProxy went away, shutting down app.
>>>> [ FAILED ] WorkerTest.SingleWorker (109607 ms)
>>>>
>>>
>>>  --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/group/chromium-dev
>>>
>>
>>
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure

[David Levin]

On Tue, Dec 1, 2009 at 2:30 PM, oshima  wrote:

> Looks like there are more tests that failing in valgrind test.
>
> shard=1 id=1513
> [  FAILED  ] WorkerTest.MultipleWorkers (103254 ms)
> [  FAILED  ] NewTabUITest.ChromeInternalLoadsNTP (74002 ms)
> [  FAILED  ] ChromeMainTest.AppLaunch (36539 ms)
> shard=2 id=1916
> [  FAILED  ] WorkerTest.IncognitoSharedWorkers (181154 ms)
> [  FAILED  ] SessionHistoryTest.FLAKY_LocationReplace (48297 ms)
> shard=3 id=1761
> [  FAILED  ] WorkerTest.SharedWorkerFastLayoutTests (731911 ms)
> [  FAILED  ] AutomationProxyTest.NavigateToURLWithTimeout1 (42516 ms)
> shard=4 id=2075
> [  FAILED  ] WorkerTest.WorkerHttpLayoutTests (119981 ms)
> [  FAILED  ] AutomationProxyTest.NavigateToURLWithTimeout2 (36359 ms)
> [  FAILED  ] UnloadTest.CrossSiteInfiniteBeforeUnloadSync (342050 ms)
> [  FAILED  ] MetricsServiceTest.CrashRenderers (49324 ms)
>
> This is not good. Is there any issue if we make a valgrind test fail when
> the test itself fails?
> If not, I'd suggest that we exclude them in ui_tetsts.gtext.txt for now
> (I'll file bugs)
> and change the test script so that a valgrind test fails when the test
> itself tails.
> Any opinion?
>
>
My quick read of this makes it sounds like you're planning to
disable various tests (like WorkerTests which can easily get broken due to
webkit changes) so that *they don't run at all* simply because valgrind
can't seem to run it.  Please don't do that.

If you're going to do changes to scripts and such, maybe you can change it
so that valgrind has some additional skip list.

Thanks,
Dave

- oshima
> On Fri, Nov 20, 2009 at 12:25 PM, Mitsuru Oshima wrote:
>
>> Hi,
>>
>> I noticed, while working on enabling valgrind test on linux/views, that
>> some of WorkerTest of ui tests in Linux Tests (valgrind) buildbot
>> are failing due to mmap failure.I tested locally with valgrind I
>> built using the script under tools/valgrind (with regular ld, but not gold),
>> and I got the same/similar mmap errors. I did quick search on bug db, but
>> couldn't find it. I'm going to file a bug, but does anyone know about this
>> problem?
>>
>> - oshima
>>
>> [==] Running 37 tests from 23 test cases.
>> [--] Global test environment set-up.
>> [--] 2 tests from WorkerTest
>> [ RUN ] WorkerTest.SingleWorker
>> [8072:8072:1120/090807:5253075177881:INFO:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/test/ui/ui_test.cc(1126)]
>> BROWSER_WRAPPER was set, prefixing command_line with
>> /b/slave/chromium-rel-linux-valgrind-tests-1/build/valgrind.tmp/browser_wrapper.ohLiPE
>> valgrind: mmap(0x3800, 1871872) failed in UME with error 22 (Invalid
>> argument).
>> valgrind: this can be caused by executables with very large text, data or
>> bss segments.
>> /b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/worker/worker_uitest.cc:28:
>> Failure
>> Value of: value.c_str()
>> Actual: ""
>> Expected: kTestCompleteSuccess
>> Which is: "OK"
>> [8078:8078:5253178758444:ERROR:/b/slave/chromium-rel-linux-valgrind-builder/build/src/chrome/browser/automation/automation_provider.cc(957)]
>> AutomationProxy went away, shutting down app.
>> [ FAILED ] WorkerTest.SingleWorker (109607 ms)
>>
>
>  --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Linux: gold linker users should upgrade to 2.20 soon.

[David Moore]

Problem solved. Coincident with using the new linker I started building the
Google Chrome build. This uses breakpad, which turns on stabs, which makes
everything slower and bigger by a factor of 5. Only do the Chrome build if
you need to is the lesson.

Dave

On Sat, Nov 21, 2009 at 8:39 PM, David Moore  wrote:

> I checked and I compiled with -O2. I see a similar slowdown in the ar
> calls. I also notice that the size of the chrome executable is now 2GB. I
> think before the size was closer to 350MB. It was 750MB if you included
> webkit symbols. Perhaps something changed about the way we're managing
> symbols.
>
> Dave
>
>
> On Sat, Nov 21, 2009 at 6:50 PM, Antoine Labour  wrote:
>
>>
>>
>> On Sat, Nov 21, 2009 at 6:24 PM, David Moore wrote:
>>
>>> Since I did this upgrade my builds have gotten very very slow. A single
>>> file change, recompile and relink used to be about 35 seconds. Now it's 2
>>> and a half minutes. As far as I can tell I'm using the right gold.
>>>
>>> davemo...@dmoorel:~/chrome/src$ ld --version
>>> GNU gold (GNU Binutils 2.20) 1.9
>>>
>>> Are other people seeing this on linux?
>>>
>>> Dave
>>>
>>
>> Make sure you compile gold with -O2. That made a huge difference for me
>> when I was playing with it, and that wasn't the default for some reason.
>>
>> Antoine
>>
>>
>>> On Wed, Nov 18, 2009 at 2:47 AM, Lei Zhang  wrote:
>>>
>>>> Hi folks,
>>>>
>>>> We'll soon be relanding a patch that pass --gc-sections to the linker
>>>> on Linux. For this to work, you need either GNU ld or a recent version
>>>> of GNU gold. You can test and see if your copy of gold is new enough
>>>> by running:
>>>>
>>>> /path/to/gold --gc-sections
>>>>
>>>> If you see: "fatal error: no input files", _no action_ is required.
>>>> If you see: "--gc-sections: unknown option", then you _need to upgrade_.
>>>>
>>>> If you installed gold through [1], please run it again. I've updated
>>>> the script at r32315 to install gold 2.20. I've also updated all the
>>>> Linux build / try bots to gold 2.20.
>>>>
>>>> [1] http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh
>>>>
>>>> --
>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>>> View archives, change email options, or unsubscribe:
>>>>http://groups.google.com/group/chromium-dev
>>>>
>>>
>>>  --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/group/chromium-dev
>>>
>>
>>
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Linux: gold linker users should upgrade to 2.20 soon.

[David Moore]

I checked and I compiled with -O2. I see a similar slowdown in the ar calls.
I also notice that the size of the chrome executable is now 2GB. I think
before the size was closer to 350MB. It was 750MB if you included webkit
symbols. Perhaps something changed about the way we're managing symbols.

Dave

On Sat, Nov 21, 2009 at 6:50 PM, Antoine Labour  wrote:

>
>
> On Sat, Nov 21, 2009 at 6:24 PM, David Moore  wrote:
>
>> Since I did this upgrade my builds have gotten very very slow. A single
>> file change, recompile and relink used to be about 35 seconds. Now it's 2
>> and a half minutes. As far as I can tell I'm using the right gold.
>>
>> davemo...@dmoorel:~/chrome/src$ ld --version
>> GNU gold (GNU Binutils 2.20) 1.9
>>
>> Are other people seeing this on linux?
>>
>> Dave
>>
>
> Make sure you compile gold with -O2. That made a huge difference for me
> when I was playing with it, and that wasn't the default for some reason.
>
> Antoine
>
>
>> On Wed, Nov 18, 2009 at 2:47 AM, Lei Zhang  wrote:
>>
>>> Hi folks,
>>>
>>> We'll soon be relanding a patch that pass --gc-sections to the linker
>>> on Linux. For this to work, you need either GNU ld or a recent version
>>> of GNU gold. You can test and see if your copy of gold is new enough
>>> by running:
>>>
>>> /path/to/gold --gc-sections
>>>
>>> If you see: "fatal error: no input files", _no action_ is required.
>>> If you see: "--gc-sections: unknown option", then you _need to upgrade_.
>>>
>>> If you installed gold through [1], please run it again. I've updated
>>> the script at r32315 to install gold 2.20. I've also updated all the
>>> Linux build / try bots to gold 2.20.
>>>
>>> [1] http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>>http://groups.google.com/group/chromium-dev
>>>
>>
>>  --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Linux: gold linker users should upgrade to 2.20 soon.

[David Moore]

Since I did this upgrade my builds have gotten very very slow. A single file
change, recompile and relink used to be about 35 seconds. Now it's 2 and a
half minutes. As far as I can tell I'm using the right gold.

davemo...@dmoorel:~/chrome/src$ ld --version
GNU gold (GNU Binutils 2.20) 1.9

Are other people seeing this on linux?

Dave

On Wed, Nov 18, 2009 at 2:47 AM, Lei Zhang  wrote:

> Hi folks,
>
> We'll soon be relanding a patch that pass --gc-sections to the linker
> on Linux. For this to work, you need either GNU ld or a recent version
> of GNU gold. You can test and see if your copy of gold is new enough
> by running:
>
> /path/to/gold --gc-sections
>
> If you see: "fatal error: no input files", _no action_ is required.
> If you see: "--gc-sections: unknown option", then you _need to upgrade_.
>
> If you installed gold through [1], please run it again. I've updated
> the script at r32315 to install gold 2.20. I've also updated all the
> Linux build / try bots to gold 2.20.
>
> [1] http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Re: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!

[David Levin]

On Fri, Oct 30, 2009 at 3:59 PM, Antoine Labour  wrote:

>
>
> On Fri, Oct 30, 2009 at 3:54 PM, Jeremy Orlow  wrote:
>
>> On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess  wrote:
>>
>>> Just to be clear for those of us who are wobbly on C++, this is
>>> because during the constructor or destructor, your object is of the
>>> class in question, NOT of the class it will finally be, because in the
>>> constructor the subclass has not been constructed, yet, and in the
>>> destructor the subclass was already destructed.  So calling to the
>>> subclass virtual implementation would be bad.
>>>
>>> Scott Meyers says: http://www.artima.com/cppsource/nevercall.html
>>>
>>> Is there any way we could modify an object to assert that it can't
>>> happen in development?  Like scoped_vtable_killer declared in the
>>> constructor and destructor which makes calling a virtual method on
>>> that object fatal?
>>>
>>
>> Or is there any sort of built in compiler warning that we could turn on?
>>  I did a bit of searching and was really surprised that I couldn't find any
>> mention of such a thing.
>>
>
> The compiler could find if it's called directly from the destructor, but
> there's no way it'd find your case ! The virtual call happens on another
> thread.
>
> To Scott's question: you can blit NULL into the vtable field, if you know
> where it is (it's not too hard, but depends on the compiler). You'll know if
> you call it - you'll die.
>

For the original issue this doesn't work b/c for virtual calls in the
constructor/destructor, the compiler may optimize them to be non-virtual.

Also, it looks like this keeps biting chromium:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475


Better yet, you could have a static table of functions that print a message
> before dying and blit that one, but that gets trickier.
>
> Antoine
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: chromium linux' Native Client Plugin hides my NPAPI plugin

[David Sehr]

If what Antoine's saying is true, it has to do with ELF symbol visibility
and the dubious concept of symbol "preemption".  The NPAPI interface should
actually only require a small number of symbols be "visible" from the
plugin, and none (the best I know) from the browser.  There's an interface
description exchange at the start of the NPAPI module that handles the rest.

There are potential performance penalties on some architectures to permit
symbol preemption, and it certainly inhibits cross-module optimization
(whenever we would get to that in our builds).  It would be best if we could
use -fvisibility=hidden for all Linux binaries -- the browser, plugins,
whatever.  It would have been better still if the Linux community had made
this crufty feature available on request rather than by default.

David

On Mon, Oct 26, 2009 at 10:10 AM, Evan Martin  wrote:

>
> On Mon, Oct 26, 2009 at 9:31 AM, Antoine Labour  wrote:
> > On Fri, Oct 23, 2009 at 1:58 AM, Anselm R Garbe 
> wrote:
> >> The problem is that the chrome
> >> executable (in particular statically linked in
> >> libnpGoogleNaClPluginChrome.a) exports 'char
> >> *NPP_GetMIMEDescription(void)' as a C symbol, which my plugin code
> >> also implements and calls when NP_GetMIMEDescription() is called by
> >> the browser. So chrome's Native Client Plugin's
> >> NPP_GetMIMEDescription() takes preference and is called by my plugin
> >> code instead of its own build-in NPP_GetMIMEDescription()
> >> implementation.
> >>
> >> [snip]
> >>
> >> However, I'm not sure if chrome resp. libnpGoogleNaClPluginChrome.a
> >> does it right with exporting these symbols as plain C symbols because
> >> this might conflict with other existing plugins as well in the same
> >> way.
> >
> > http://gcc.gnu.org/wiki/Visibility
> > Make your plugin compile with -fvisibility=hidden, and only explicitly
> > export the plugin functions by adding
> __attribute__((visibility("default")))
> > That should fix this, and similar problems.
> > Though agreed, Chrome should aim to do the same...
>
> I recall looking into this before, but I didn't fully understand what
> I was doing.
>
> I think what you're saying is that Chrome by default exports all its
> symbols to plugins embedded within it, even if those symbols may
> conflict with the plugin's symbols.  Doesn't NPAPI specify the limited
> set of symbols (the NPN_*) we should provide, or is there more (like
> malloc) that are implicitly shared?
>
> Since I don't know what I'm talking about, can you file a bug with a
> recommendation as to what we should be doing?
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Crashing layout tests

[David Levin]

If it isn't written here
http://dev.chromium.org/developers/how-tos/webkit-merge-1, then (imo) it
isn't policy for gardener. :) Given that not everyone is in the same place,
if it isn't written in the standard place, how will folks know?
Even then, if you add something new, it would be nice to tell folks b/c I'm
sure not everyone checks that every time they start gardening.

dave

On Tue, Oct 20, 2009 at 10:25 AM, Jeremy Orlow  wrote:

> On Tue, Oct 20, 2009 at 10:19 AM, David Levin  wrote:
>
>> That sounds like a reasonable policy.
>
>
> Hmm...I thought this was the policy.  I guess not?  :-)
>
>
>> There is the current idea of figuring out something about the crash before
>> filing a bug, which clashes with this idea.
>> What text would you add to
>> http://dev.chromium.org/developers/how-tos/webkit-merge-1 to tell how to
>> deal with these? Here's one idea (add it in red?):
>>
>> If you must roll WebKit DEPS and pick up new crashers, you should enter an
>> individual bug for each new crasher immediately and make it P0.
>>
>>
>> Then what about assigning. Does it go to the unlucky webkit gardener who
>> happened to have the duty that day? (If they have another day of gardening,
>> then these bug linger.)
>>
>
> If the gardener has time, sure.  If not, maybe assign it to whomever makes
> the most sense.  And, when there's no obvious candidate, they can draft
> someone.  (In general, I think we should empower gardeners to draft people
> when there are lots of high prioirity items stacking up and/or we get really
> behind ToT.)
>
> On Tue, Oct 20, 2009 at 9:23 AM, Jeremy Orlow  wrote:
>>
>>> Today I noticed a bunch of recently added CRASH test expectations for
>>> layout tests.  I know that we sometimes have to roll in a crasher or two,
>>> but aren't we supposed to be filing p0-p1, dev channel release blockers at
>>> least until we can prove the crash is not exploitable in the browser and
>>> ideally not before the crash is fixed??
>>> Btw:
>>> $ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
>>>   56
>>>
>>> And many of them are fairly new.
>>>
>>> J
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Running applications in chrome with javascript

[David]

Someone knows where is a good guide for make an npapi plugin? and how
to call function to execute process...

thanks!

On 16 oct, 09:56, Daniel Wagner-Hall  wrote:
> NPAPIlets you execute native 
> code:http://code.google.com/chrome/extensions/npapi.html,https://developer.mozilla.org/en/Plugins
>
> On Fri, Oct 16, 2009 at 8:16 AM, David  wrote:
>
> > nobody knows how to run an exe in chrome... is it possible?
> > thanks!
>
> > On 13 oct, 17:35, David  wrote:
> >> hi!
>
> >> i want to know how to run an applicacion with the chrome, as the same
> >> as activeX in IE and xpcom interfaces in Mozilla...
>
> >> thanks!
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Running applications in chrome with javascript

[David]

nobody knows how to run an exe in chrome... is it possible?
thanks!

On 13 oct, 17:35, David  wrote:
> hi!
>
> i want to know how to run an applicacion with the chrome, as the same
> as activeX in IE and xpcom interfaces in Mozilla...
>
> thanks!
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] hi!

[David]

-

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Running applications in chrome with javascript

[David]

hi!

i want to know how to run an applicacion with the chrome, as the same
as activeX in IE and xpcom interfaces in Mozilla...

thanks!

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: seeking webkit reviewer for chrome-specific patches

[David Levin]

On Tue, Oct 13, 2009 at 6:02 PM, Evan Stade  wrote:

>
> 3. It is unclear if there are any layout tests which cover this change.
>>
>
> I don't think layout tests can or should cover that change, except for
> pixel tests, which will just need to be rebaselined.
>

Right so are there pixel tests which cover this? Maybe that isn't possible.

WebKit patches should say one of the following about (layout) tests:
1. what tests cover the functionality
2. have new tests that cover the functionality
3. explain why a test isn't needed
4. explain why a test isn't possible

This patch does none of those which is what I was attempting to point out in
a less verbose manner.

dave

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: seeking webkit reviewer for chrome-specific patches

[David Levin]

I glanced at the other one. there were a few issues with it:
1. It does more than it says. It changes how the horizontal lines are drawn
without explanation (nothing in the changelog and the bug only mentions the
other direction).
2. It uses a lot of "magic" numbers and the same ones repeatedly. It would
be nice to make constants out of some of them to help inform the reader
where they come from.
3. It is unclear if there are any layout tests which cover this change.

I would be happy to r- if you want :) but am uncomfortable with an r+ due to
those reasons.



On Tue, Oct 13, 2009 at 5:25 PM, Evan Martin  wrote:

>
> dimich looked at one.  Any reviewer for the other?  It's like 8
> obvious Linux-specific lines, no stress I promise.  :)
>
> On Tue, Oct 13, 2009 at 4:06 PM, Evan Martin  wrote:
> > Both of these patches don't really have an obvious reviewer, but
> > they're pretty simple.
> >  https://bugs.webkit.org/show_bug.cgi?id=30319
> >  https://bugs.webkit.org/show_bug.cgi?id=30320
> >
> > The latter one will require an epic amount of rebaselining, which I
> > have volunteered to do.  If anyone has advice on how to do that in a
> > way that makes the webkit sheriffs happy, let me know.
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

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

[David Levin]

> A better solution would be to have the sheriff (or someone from LTTF)
assign the bugs to specific people
So how do you figure out who to assign it to?

> with a general rule that such bugs must be fixed within two days (make
these bugs the top priority over other tasks).
Over security bugs?
Over code reviews which other people need (some of which are large and
involved)?
Over interviews and feedback (if your company is doing this)?
Over fixes for a release with a given deadline that may be looming?
Over your next round of WebKit gardening?
Over fixing a top crasher?
:)

> This allows for load balancing of bugs, and also makes sure that we have
the right people working on any specific bug.
As long as one area isn't broken disproportionally or somehow one person
isn't assigned bugs disproportionately.

> First two days you roll. Next two days you fix layout tests. The net
result of 4 days should be 0 (or less!) new layout test failures.
Not all WebKit gardening days are equivalent and some will take quite a bit
of time to clean up. For example, what happens when someone add structured
clones for JSC and we fail the associated layout test? Does the person on
that rotation end up getting a new feature to implement?

Or if we take Drew's approach, do we make Drew drop what he is doing to
implement structured clones, since they are most closely associated with
MessagePorts?

I don't know the right answer but I don't feel like it is there yet

> Assign LTTF folks specifically for test clean-up every day. ... appears to
separate the action/responsibility dependency.
*There already is a separation of action from responsibility*.  For example,
in yesterday's tragic roll, it shouldn't have been done, but the real action
was not done by hclam. It was done by the person who created the v8 patch,
and there is no responsibility for the havoc and mess caused by that change.
This happens frequently to the gardener.
My vote: I lean closest to assigning something like the LTTF folks to clean
up recent failures and have rotating duty on to do this for maybe a week or
two at a time (even after LTTF is ended). With the ability to pull
in/assign/hassle other folks to fix/investigate issues if it is beyond the
knowledge of folks on that team.

If you have something like the LTTF folks cleaning up, then it seems
possible to get more people doing the WebKit gardening. Perhaps, if you are
on what I'll call "the LTTF rotations", then you don't have to do the
gardening, but you are available to help gardener if they hit some build
break that they don't know how to deal with.

Dave


On Tue, Oct 13, 2009 at 10:53 AM, Drew Wilson  wrote:
> I've been thinking quite a bit about this - I agree with Dmitri that the
> current Sisyphean approach is unsustainable.
> I don't think the right path is to ask the sheriffs to do the cleanup
> themselves - for example, a webkit roll that breaks workers in some
obscure
> way is almost certainly beyond the ability of any random gardener to fix
in
> two days, especially when there may be multiple bugs.
> A better solution would be to have the sheriff (or someone from LTTF)
assign
> the bugs to specific people, with a general rule that such bugs must be
> fixed within two days (make these bugs the top priority over other tasks).
> This allows for load balancing of bugs, and also makes sure that we have
the
> right people working on any specific bug.
> -atw
> On Tue, Oct 13, 2009 at 10:40 AM, Pam Greene  wrote:
>>
>> I don't think it's realistic to expect the gardener, or any one person,
to
>> be able to fix an arbitrary broken layout test in a reasonable period of
>> time. That's certainly true for new tests, but even for regressions I
often
>> can't even tell for sure whether our results are correct, much less what
to
>> do if they're not.
>> It's far more efficient to have the "right" person fix a test. (Of
course,
>> people should also strive to broaden their knowledge, but there's a limit
to
>> how much of that one can do in a week.) Never having broken layout tests
is
>> an excellent goal, but quite frankly I don't think it's one we should
>> prioritize so high that we hobble other efforts and burn out developers.
>> - Pam
>> On Tue, Oct 13, 2009 at 10:31 AM, Dimitri Glazkov 
>> wrote:
>>>
>>> I think we need to change something. I am not sure what -- I have
>>> ideas, but -- I would appreciate some collective thinking on this.
>>>
>>> PROBLEM: We accumulate more test failures via WebKit rolls than we fix
>>> with our LTTF effort. This ain't right.
>>>
>>> ANALYSIS:
>>>
>>> Ok, WebKit gardening is hard. So is fixing layout tests. You can't
>>> call it a successful WebKit roll if it breaks layout tests. But we
>>> don't revert WebKit rolls. It's a forward-only thing. And we want to
>>> roll quickly, so that we can react to next "big breaker" faster. So
>>> we're stuck with roll-now/clean-up-after deal. This sucks, because the
>>> "clean-up-after" is rarely fully completed. Which brings failing

[chromium-dev] Re: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.

[David Levin]

The webkit api won't help if chromium folks (especially when you change v8
bindings) don't *run the layout tests *which is what happened yesterday and
causes quite a few of our worst problems while gardening.
If you're changing the v8 bindings, you're doing it to fix a problem in
chromium, so you must have a build of chomium (and thus be able to run
layout tests).

dave

On Mon, Oct 12, 2009 at 11:40 PM, Darin Fisher  wrote:

> On Fri, Sep 25, 2009 at 10:21 AM, Jeremy Orlow wrote:
>
>> On Fri, Sep 25, 2009 at 10:01 AM, Amanda Walker wrote:
>>
>>> On Tue, Sep 22, 2009 at 9:06 PM, Dimitri Glazkov wrote:
>>>
 This all means that we have to be a bit more diligent. We shouldn't be
 paying these unnecessary costs. So, from now on, I propose a fairly
 simple set of new rules:

 1) if you write a Chromium patch for WebKit, you must provide URLs of
 successful trybot runs with your submission. Chromium WebKit reviewers
 will not r+ your patch otherwise. If you can't provide the trybot URLs
 for some reason, please explain in detail why this patch could still
 land.

 2) if the two-sided patch you authored broke the canary and this
 happened with no coordination with the WebKit gardener, you assume
 WebKit gardening responsibility for the next 24 hours.

 Hopefully, these amendments to our existing ways will bring a bit more
 peace and stability to the Chromium land. What do you think?

>>>
>>> I think they're a good start, but they are symptoms of a larger problem.
>>>  "Move fast and clean up messes when they happen" worked great when we had
>>> one big mess a week.  These days, we have multiple ones per day.  And as
>>> good as the try bots and canaries are (kudos to M-A for setting up the try
>>> bots in the first place, and everyone who helps keep the ever-growing herd
>>> of bots running), they don't catch everything.  They don't catch build time
>>> regressions because someone forgot svn:ignores when refactoring where
>>> projects get generated, or accidentally checks something into the wrong
>>> directory (not to pick on anyone in particular, these are just recent
>>> examples).
>>>
>>> I'd add a 3rd principle:
>>>
>>> 3) If you change how chromium is built, however innocuous your change
>>> seems (gyp changes, new libraries, etc.), take extra care and use more
>>> reviewers than usual (preferably including someone intimately acquainted
>>> with the bots, such as maruel, thomasvl, markmentovai, nsylvain, etc.).  If
>>> you're reviewing such a change, don't just look at the diffs, try out the
>>> patch and flag anything that seems out of the ordinary.  "Build breakage"
>>> means more than just "doesn't compile"; it can also mean "overcompiles"
>>> (which kills bot performance) or "requires a clobber unnecessarily."
>>>
>>
>> I had to land a 2 sided patch yesterday.  It blew up an important unit
>> test in a very creative way, and we're still trying to figure out how to
>> clean it up nicely.  In the mean time, we have a dev channel release
>> blocker.  There has to be a better way...
>>
>> Here's a crazy idea:
>>
>> 4) Create a WebKit.next branch.  Have full build bot coverage on it.  All
>> integrations would go through it.  Other than that, only 2 sided patches
>> would land on it.  Whenever everything passes, we'd merge in with the main
>> branch.  We'd try very hard never to let it get more than a day or so out of
>> sync.
>>
>> This would make 2 sided merges (which are often the reason for rushing a
>> DEPS roll--don't want to keep the canary red for too long, otherwise it's
>> very hard to sort things out) much less haphazard.  We could even have it
>> roll the DEPS automatically every time a new webkit.org patch lands, and
>> thus eliminate our need for dedicated canaries.
>>
>> Yeah, it's crazybut I kind of like it.  And yeah, when the WebKit API
>> lands things should be better in terms of others breaking us, but this
>> addresses 2 sided patches...which are not going away any time soon.
>>
>> J
>>
>>
> I think we should just finish the WebKit API :-)
>
> Here's the bug list:
> http://code.google.com/p/chromium/issues/list?q=label:WebKitAPI
>
> I'm looking for volunteers to help take on some of these tasks.
>
> -Darin
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: WebKit Chromium Port Update Sep 29th

[David Levin]

On Tue, Sep 29, 2009 at 10:41 PM, Darin Fisher  wrote:

> Yeah, good point... this could be a good task for gardeners.  Perhaps we
> could have a tool help us here.


Maybe there could be a test run on the canary that checks the DEPS to see if
they have the same versions, and if they aren't, it turns "orange" to
indicate some action should be taken.



> -Darin
>
>
> On Tue, Sep 29, 2009 at 10:26 PM, Dmitry Titov wrote:
>
>> It seems that if the deps were the same though, the rolls would be on
>> average less breaking because at least it would test WebKit on WebKit bots
>> with same versions of V8, Skia etc as post-roll. So single DEPS could make
>> gardening simpler but other changes (like update Skia for UI) harder. I see
>> the point. Yeah, it is optional for gardener to roll WebKit DEPS,
>> although someone will have to do this periodically so why not?
>>
>>
>>
>> On Tue, Sep 29, 2009 at 9:08 PM, Darin Fisher  wrote:
>>
>>> That seems optional to me.  I don't see why it matters that much.  The
>>> canary bots will still be using DEPS from svn.chromium.org, so we should
>>> get sufficient coverage there.  That will allow us to be confident about
>>> updating WebKit, right?
>>> The upstream builder is first and foremost designed to help non-Chromium
>>> WebKit contributors build and repair the PLATFORM(CHROMIUM) port.  So, all
>>> we need for that is a stable set of dependencies.  They don't strictly
>>> speaking need to be up-to-date unless there is an interface change of
>>> course.
>>>
>>> -Darin
>>>
>>>
>>> On Tue, Sep 29, 2009 at 8:44 PM, Dmitry Titov wrote:
>>>
>>>> I guess WebKit gardener will need to bump the WebKit DEPS to the version
>>>> numbers from Chromium if Chromium's go ahead... To have more predictable
>>>> result of roll and to keep them more or less in sync...
>>>>
>>>>  On Tue, Sep 29, 2009 at 7:43 PM, Darin Fisher wrote:
>>>>
>>>>>  That's basically what we had before.
>>>>> You can add entries to a DEPS file that have the value From("foo"), and
>>>>> that causes the value of the entry to be taken from the path foo/DEPS, 
>>>>> where
>>>>> foo is a directory at the same level as the directory containing the DEPS
>>>>> file that mentioned From("foo").  Originally, chrome's DEPS file lived in
>>>>> chrome/DEPS instead of src/, and the submodules were the ones that were
>>>>> siblings to the chrome directory.
>>>>> There's a lot of shared dependencies.  I'm not sure that for trunk
>>>>> development, it makes sense to require a WebKit roll to update DEPS for 
>>>>> all
>>>>> of those shared dependencies.  I'm concerned that will slow us down.
>>>>>
>>>>> Can we try having separate sets of dependencies for now?  I think the
>>>>> point of the WebKit standalone build is to help vet changes to WebCore.  
>>>>> It
>>>>> is less about vetting changes to the modules.  The canary bot can cover
>>>>> those.
>>>>>
>>>>> We could write a tool to sync deps, which we run periodically.  I think
>>>>> the Chromium repository should probably hold the truth.
>>>>>
>>>>> -Darin
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 29, 2009 at 4:46 PM, David Levin  wrote:
>>>>>
>>>>>> What about the override approach that I mentioned?
>>>>>> Have the dependency listed in webkit alone. If you need to roll the
>>>>>> deps before rolling webkit, add a line in the chromium deps that 
>>>>>> overrides
>>>>>> the one from webkit.
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 29, 2009 at 3:00 PM, Darin Fisher wrote:
>>>>>>
>>>>>>> On Tue, Sep 29, 2009 at 1:12 PM, David Levin wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> > Q: When I change src/DEPS, do I also have to change upstream
>>>>>>>>> > third_party/WebKit/WebKit/chromium/DEPS?
>>>>>>>>> > A: It depends why you update src/DEPS. Theoretically, you should
>>>>>>>>> only update
>>>>>>>>> > the upstream DEPS if the fix t

[chromium-dev] Re: WebKit Chromium Port Update Sep 29th

[David Levin]

What about the override approach that I mentioned?
Have the dependency listed in webkit alone. If you need to roll the deps
before rolling webkit, add a line in the chromium deps that overrides the
one from webkit.


On Tue, Sep 29, 2009 at 3:00 PM, Darin Fisher  wrote:

> On Tue, Sep 29, 2009 at 1:12 PM, David Levin  wrote:
>
>>
>>
>> > Q: When I change src/DEPS, do I also have to change upstream
>>> > third_party/WebKit/WebKit/chromium/DEPS?
>>> > A: It depends why you update src/DEPS. Theoretically, you should only
>>> update
>>> > the upstream DEPS if the fix to the dependency actually changes the way
>>> > webkit interacts with it, or fixes a bug in the webkit layout tests.
>>> > However, if the change is only relevant to chromium, than webkit's DEPS
>>> need
>>> > not be updated. If that change breaks webkit, we will surely find it
>>> when we
>>> > build chromium.
>>>
>>
>> This seems like a mistake having out of sync rev may cause all sorts of
>> issues. Here's a simple one suppose there is a rev that fixes some issue and
>> adds an assert and it is only done in chromium.
>>
>> Now code is changed in webkit which would trigger this assert. This
>> increases the pain for rolls and seems like a mistake.
>>
>>
> Ask anyone who was around when we had transitive deps.  It royally sucked.
>  I really do not want to go there again ;-)
>
> Once we finish the WebKit API, we'll be able to make Chromium tip-of-tree
> use a snapshot of WebKit.  However, we might need to rev Skia independently
> to pick up features for the Chrome UI.  We shouldn't have to branch WebKit
> just to update Skia.  Same goes for the majority of the shared dependencies.
>
> I think it is better if we have two separate configurations.  Testing
> WebKit in isolation just depends on some reasonable set of dependencies.
>  Then, we'll also test Chromium+WebKit(head) using the canary bots.  This
> will test with dependencies matching those used by Chromium+WebKit(stable).
>  So, I think we'll get the coverage we need.
>
> Another choice is to have a shared master location for dependencies.
>  However, both svn.webkit.org and svn.chromium.org would need to hardcode
> the revision of that master location, so you are back to having to rev a
> number in two locations.  We don't want to have either repository pointing
> to the head of the master location since that would make it difficult to cut
> branches or refer to a particular revision of the repository.
>
> -Darin
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: WebKit Chromium Port Update Sep 29th

[David Levin]

> Q: When I change src/DEPS, do I also have to change upstream
> > third_party/WebKit/WebKit/chromium/DEPS?
> > A: It depends why you update src/DEPS. Theoretically, you should only
> update
> > the upstream DEPS if the fix to the dependency actually changes the way
> > webkit interacts with it, or fixes a bug in the webkit layout tests.
> > However, if the change is only relevant to chromium, than webkit's DEPS
> need
> > not be updated. If that change breaks webkit, we will surely find it when
> we
> > build chromium.
>

This seems like a mistake having out of sync rev may cause all sorts of
issues. Here's a simple one suppose there is a rev that fixes some issue and
adds an assert and it is only done in chromium.

Now code is changed in webkit which would trigger this assert. This
increases the pain for rolls and seems like a mistake.



> > Q: Why don't we control webkit's dependencies in a single place?
> > A: Most of the dependencies that webkit uses are also used directly by
> > chromium. Therefore, we will often find ourselves rolling webkit
> revisions
> > just because chromium needs a third party revision update. We have been
> > there once, it was painful, we don't want to go there again.
>

Why not just allow an override in chromium's deps file?  This way if one
really needs to change a rev without doing a webkit roll there is a way but
ideally there would be one place where the deps are specified.

Everytime there is duplicate information that may get out of sync and cause
wierd errors, it increases the complexity of the system which is a bad
thing.

dave

>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: SVN hangs updating third_party/WebKit

[David Levin]

For windows (vista 64bit?), if you hit gclient hangs in general while
sync'ing:

Run this command (from an Administrator command prompt): netsh interface
tcp set global autotuninglevel=disabled

Hopefully, it will be fixed for you as it seems to be for me.

Reference:
http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx



On Fri, Sep 25, 2009 at 5:22 PM, Nico Weber  wrote:

>
>
> http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba
>
> I had the impression that removing that folder once is enough, though
> I didn't try it more than once yet.
>
> On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson
>  wrote:
> > At first I thought it was a fluke but now it just happened again. Is
> anyone
> > else seeing this?
> > I do a gclient sync and it takes forever, showing this output and looks
> > hung:
> >
> >  running 'svn update E:\code\src\third_party\WebKit --revision
> > 27219' in
> >  'E:\code'
> > I wait and wait and wait and wait and nothing happens. I tried FileMon
> and
> > couldn't see any files being accessed. Re-running gclient sync just hangs
> > again in the same spot.
> > The only workaround I know is to delete that folder and try again. That
> was
> > fine for the first time this happens, but is getting more exponentially
> more
> > frustrating with each time I have to do that. :s
> > Anyone seen this?
> > -F
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Webkit merges and tree closures

[David Levin]

+1!

On Thu, Sep 24, 2009 at 8:55 AM, Dimitri Glazkov wrote:

>
> BTW, huge kudos to STP folks for jumping on that and getting it fixed.
> Vitaly and Pavel, you are our secret weapon.
>
> :DG<
>
> On Thu, Sep 24, 2009 at 12:03 AM, Jeremy Orlow 
> wrote:
> > On Tue, Sep 22, 2009 at 6:10 PM, Jeremy Orlow 
> wrote:
> >>
> >> There are 2 major issues here (besides leaving things for the Sheriff to
> >> clean up):
> >> 1) a lot of the gardeners are inexperienced and drop the ball.  This has
> >> bitten us many times.  The last time we had a big string of problems
> related
> >> to this, I meant to send out an email giving people advice on what to
> expect
> >> and how to prepare.  I will do it this time.  Hopefully people listen.
> >> 2) we don't have enough tools for gardeners to do their jobs.  As I
> >> mentioned in another thread you started the other day, we really need
> more
> >> try bots and/or canaries that run memory tests, our full suite of tests,
> >> etc.  Without that, things are not going to get better.
> >> Just to be clear, on bad days, gardening is WAY harder than sheriffing
> by
> >> yourself.
> >
> > Case in point, look at this CL that just landed and broke us in some
> pretty
> > scary ways: http://trac.webkit.org/changeset/48701
> > I tried to fix it, but it looks to be anything other than a "quick fix".
> >  :-(
> > J
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Webkit merges and tree closures

[David Levin]

On Wed, Sep 23, 2009 at 8:53 AM, Glenn Wilson  wrote:

> I'll take the action item to remove anyone in the rotation who is not
> actively working on Webkit / is not a committer.
>

Oh no... now it will happen even more often :)

Should there also be the reverse adding WebKit committers who are not
gardeners to the rotation?


> In the past, I've floated the idea in the past of having a "Webkit deputy"
> who helps the gardener keep the canary green.  I'm not sure if that would
> help, though.
>

fwiw, earlier in the thread I gave 5 things that would definitely help --
For those concerned about this issue, if you tackle these, it would make
things go smoother.

dave

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Webkit merges and tree closures

[David Levin]

I find that being a WebKit gardener is always dancing on a minefield
regardless of my familiarity with the WebKit code base. Look at yesterday
for an example.
In addition, we have several gardeners who are not actively working on
WebKit (amanda@ has 0 WebKit commits, pinkerton@ has a few all in 2008).

Lastly, can we add anyone to the rotation who has ideas how WebKit gardeners
should/can do their job better? (This will help them in getting more ideas.)

Dave

On Wed, Sep 23, 2009 at 7:53 AM, Dimitri Glazkov wrote:

> On Wed, Sep 23, 2009 at 7:46 AM, Mike Pinkerton 
> wrote:
> >> It is hard to be a WebKit gardener if you do not have WebKit commit
> access.
> >> Sometimes the gardener has to commit a quick bustage fix upstream or
> roll
> >> back a fellow Chromium committers change to WebKit.
> >> -Darin
> >
> > Correct, it is hard, but many/most of us who are webkit
> > sheriffs/gardeners are not webkit committers (for example, the entire
> > mac group). I don't understand your point. Are you saying that only
> > webkit committers should be on the webkit sheriff rotation?
>
> In my experience, better familiarity with WebKit code base is a huge
> advantage for a gardener. I am almost tempted to say that if you're
> not actively working on WebKit, being a gardener will be a foreign and
> "dancing-on-a-minefield"-type task.
>
> :DG<
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Webkit merges and tree closures

[David Levin]

Actionable items for keeping the tree green (in addition to blaming the
WebKit gardener for [insert action here]):

   - *Get people putting in chromium patches upstream to run their changes
   through trybots, etc*. imo, patches from @chromium folks cause well over
   50% of the grief with WebKit rolls (and usually the worst issues like
   today).
   - As Adam suggested, *make changes to the WebKit commit queue to run
   items through the chromium try bots*.
   - *WebKit gardeners should be able to submit high priority jobs to the
   try bots*. These jobs should job to the front of any queues so that they
   run asap.
   Why? Time is critical when doing the gardening because if you find a
   breakage upstream, you need to check in a fix and then roll to that fix. The
   longer the delay, the more likely another breakage will be checked in.
   - *Consider auto-rolling WebKit deps*. Have the something like a parallel
   buildbot that runs against tip of tree WebKit. If everything passes except
   layout tests, add any layout test failures to test_expectations.txt (if
   there are less than 15) and roll DEPS on passing. If things fail, then turn
   red.
   - *Make it easier/faster to disable tests and file bugs about them *(using
   the last person in the "blame/annotate" for the test as the initial assignee
   or auto-assign it to the sheriff so (s)he can assign it to the right person)
   * *because issues will slip from WebKit rolls even though the gardeners
   try to be thorough. Also, this should help with turning the tree green in
   other cases as well.

The sheriff (and everyone on the chromium team) should care about the WebKit
roll as this is critical to the success of this project. Frequent rolls,
should isolate issues and hopefully help to keep the tree green.
*
*
To help shed some light on why WebKit gardening is more painful than
sheriffing:

   1. WebKit gardeners are all alone in trying to deal with things.
   2. When things go bad on the canary, no one shuts down the tree for you
   and any changes to help with merging are not given priority (if the tree is
   red and you have an innocuous change to fix the webkit merge, you won't get
   it in.)
   3. When tests fail anywhere (on the canary, when committing the roll,
   etc.), you have to figure out why, typically for a lot of changes that you
   know nothing about.
   4. Two days of gardening -- multiple days of clean up afterward.
   5. WebKit gardening occurs more often than sheriff duties.
   6. afaik all WebKit gardeners also have sheriff duties.

Net: chromium sheriffs please be willing to give a little extra help to the
WebKit gardener. Remember that their hair is turning white as they try to
run in front of a locomotive.

Dave

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Git questions

[David Levin]

I like to use multiple directories using git-new-workdir (
http://www.google.com/search?q=git-new-workdir).
I tend to keep one directory for "trunk" and one for whatever branch I'm
working on (and if I'm working on a few branches, then I'll keep a few
directories).  I still swap branches in the different directories at times
but this way I can keep files from being modified unnecessarily when I'm
working on a particular branch and want to rebase or want to do a quick
change on a another branch, etc.

This solves several of your issues.

dave



On Fri, Sep 18, 2009 at 8:48 AM, Nico Weber  wrote:

>
> Oh, and I forgot one:
>
> 3.) When I switch branches, XCode likes to rebuild a lot of stuff
> (considerably more than necessary), which takes forever (30-90 min) on
> my machines, which makes switching branches very heavyweight for me –
> enough so that I considered having multiple independent checkouts.
> Does anybody else see this / have a good answer to this? (This seems
> to happen more often recently (?))
>
> Also, XCode seems to get very confused and slow if it's open while I
> switch branches, so I started to close my current project while
> switching branches and reopen the project afterwards. This results in
> XCode having to do a lot of "Checking Dependencies…" even if it
> decides to not rebuild the whole project.
>
> Anybody else seeing this? (I guess this point won't have actionable
> answers, as it's more of a diffuse complaint :-P)
>
> On Fri, Sep 18, 2009 at 8:27 AM, Nico Weber  wrote:
> > In which the author reveals that he is a complete utter git n00b.
> >
> > Hi folks,
> >
> > I've been using git instead of svn for about 2 months now. Overall,
> > I'm a happy user, but there are a few issues. Perhaps someone can help
> > me with them.
> >
> > 1.) When doing `git cl dcommit`, I always get
> >
> >   "Transaction is out of date: File
> > '/trunk/src/chrome/app/generated_resources.grd' is out of date at
> > /opt/local/libexec/git-core/git-svn line 469
> >
> >   Command "git svn dcommit --no-rebase" failed.
> >
> > at first. The first few times, I tried a `git svn rebase`, but that
> > always told me that
> >
> >   Last fetched revision of refs/remotes/origin/trunk was r22892, but we
> are
> >   about to fetch: r21840!
> >
> > and didn't help. Now I always do `rm -rf .git/svn && git svn fetch`
> > before `git cl dcommit`. After that, `git cl dcommit` then tells me
> > that
> >
> >   Base branch "refs/remotes/origin/trunk" has 24 commits not in this
> branch.
> >   Run "git merge refs/remotes/origin/trunk" before attempting to dcommit.
> >
> > which I do, and after that committing works. However, blowing away all
> > svn information and regenerating it each time seems stupid. What am I
> > doing wrong, and how can I do it better?
> >
> > 2.) I often have 3-5 feature branches. When one of them is of them is
> > getting ready to submit, I usually rebase it on ToT before sending it
> > to the try servers. I do this thusly:
> >
> >   git checkout trunk
> >   git pull
> >   git checkout myfeaturebranch
> >   git rebase trunk
> >
> > (this can probably be done in an easier way, but it works and is
> > easily put into a bash alias, so I looked only briefly for a better
> > way, and didn't find anything). Now, when I want to work on the other
> > branches, I always rebase them to trunk when I switch to them, i.e. I
> > run
> >
> >   git checkout otherbranch
> >   git rebase trunk
> >
> > If I didn't use that branch for a week or so, the first step takes
> > quite some time to remove all the changes that I pulled in since last
> > using my branch, while the second step takes about the same time to
> > undo all the work that the first step did, which seems stupid. Is
> > there a command for "go to that branch, but rebase it immediately"?
> >
> > Thanks,
> > Nico
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

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

[David Levin]

Nice write up.

Idea by Drew Wilson:
5. Make test shell dump (partial) results when there is a timeout. (This may
actually be an item under "2".)

On Wed, Sep 9, 2009 at 10:51 AM, Ojan Vafai  wrote:

> 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. Look at the actual results off the bots for the non-timeout flaky
>failures and identify the cause of the flakiness (likely the test itself).
>4. Make test_expectations.txt match what's actually happening on the
>bots (see the flakiness dashboard for tests with incorrect expectations).
>
> All the data I use below is from:
> http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html
>
> On Tue, Sep 8, 2009 at 5:52 PM, David Levin  wrote:
>
>> I agree that the chromium buildbot seems to have more flakiness on layout
>> tests that webkit buildbots.
>
>
> While there is definitely more flakiness, I'm not sure how much more. I
> think the Chromium bots are primarily more flaky on the HTTP tests. What
> flakiness there is gets less noticed on the webkit buildbots since they
> don't close the tree.
>
>
>> Here's two things that may help us to understand this:
>> 1. It would be nice to save crash logs from OSX into the zip file. For
>> example, this run
>>
>> http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20(dbg)(2)/builds/3323/steps/webkit_tests/logs/stdio
>> had a crash and likely generated a crash log at
>> ~/Library/Logs/CrashReporter/TestShell*.crash which would help point to a
>> culprit.
>>
>
> +1 This would be very useful. That said, it won't benefit with decreasing
> flakiness much. Very few of the flaky tests are flaky crashers. They're
> almost entirely flaky timeouts or failures, even in debug builders.
>
> 2. If we suspect that tests may pass if given more time, then increase the
>> timeout and see if more tests pass but exceed this old timeout (log
>> something when this happens so we can validate that it is working).
>>
>
> -1 The test dashboard prints the out the amount of time a test takes to run
> if it takes >1 second. I don't think the timing out tests would pass if we
> just gave them more time. Specifically, there are tests that always timeout
> and there are flaky timeout tests. The flaky timeout tests, when they do
> pass, consistently take less than 10 seconds to run, most of them take less
> than 1 second.
>
> Increasing the test timeout also *considerably* increases how long it takes
> for the bots to cycle. In fact, I think we should be *decreasing* it to
> something like 2 seconds. This would actually shave minutes off of the
> current bot cycle times.
>
> We have ~100 tests that are slow, many of which timeout at 20 seconds. We
> should mark all the slow, but passing tests as SLOW in the test expectations
> file. This will give them more time to run than the other tests. Then we
> should bring the timeout down to something like 2 seconds. This will make
> the bots run a lot faster and distinguish between the tests that timeout
> versus just taking a long time to pass.
>
>
>> On Tue, Sep 8, 2009 at 5:41 PM, Dirk Pranke  wrote:
>>
>>> From what I've poked around at, many of the LayoutTest flaky failures
>>> are timeout-related.
>>
>>
> While more than half of the flaky tests on Windows and Mac are timeouts,
> many of them are crashes or failures. You can see this pretty clearly on the
> layout test dashboard. I'll note that on Linux, a very small percentage of
> the flakiness is timeouts. Almost all of these timeouts on Windows/Mac are
> HTTP tests. There is likely one or two causes for all the flakiness with the
> HTTP tests.
>
> There's something in the test harness and web
>>> server configurations that cause tests to be unpredictably slower. I
>>> don't think Apple has this problem, and I think that's because they
>>> use the built in apache instance in OS X,
>>
>>
> We switched away from apache to lighttp because of flakiness it was causing
> on cygwin (cygwin and apache don't play well together). Maybe it makes sense
> to use lighttp on Windows and Apache on Mac? I think we should identify the
> cause of the flakiness on Windows. Fixing that might fix the flakiness on
> Mac as well and we wouldn't need to support two http servers.
>
>
>> and also be

[chromium-dev] Re: WebKit Chromium Port

[David Levin]

On Tue, Sep 8, 2009 at 11:02 PM, Jeremy Orlow  wrote:

> This has not always been true in the past.  I think we (people working on
> Chromium) made a good effort to help bring real code review infrastructure
> to WebKit and that was a disaster (though maybe I don't know the full story
> and we were in the wrong).
>

Sounds like us vs them again.

>From what I saw in this case, things were done quickly without getting buy
in. I saw at least one irc conversation in which folks had expressed their
concerns about being asked about changes and then things done in less than
an hour without giving time for a response. From this, it appeared to me
that the effort may not have been handled in the best way.

I have seen several WebKit reviewers who appear to be willing to consider a
new code review tool, but there are lot of things to fix in the process, and
there are a fair number of concerns about how some new would fit into the
WebKit process. There was an email that outlined an approach to addressing
process issues in WebKit, and it had evaluating new code review tools in
there.

I have also seen folks try to push chromium solutions on webkit in cases
where it didn't make sense.

This reminds me of the debates of git vs svn (or emacs vs vi, etc.). Each
has their potential advantages, but adopting something new requires changes
that may be painful so change takes time.

Dave

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

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

[David Levin]

I agree that the chromium buildbot seems to have more flakiness on layout
tests that webkit buildbots.
Here's two things that may help us to understand this:
1. It would be nice to save crash logs from OSX into the zip file. For
example, this run

http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20(dbg)(2)/builds/3323/steps/webkit_tests/logs/stdio
had a crash and likely generated a crash log at
~/Library/Logs/CrashReporter/TestShell*.crash which would help point to a
culprit.

2. If we suspect that tests may pass if given more time, then increase the
timeout and see if more tests pass but exceed this old timeout (log
something when this happens so we can validate that it is working).

Dave

On Tue, Sep 8, 2009 at 5:41 PM, Dirk Pranke  wrote:

>
> From what I've poked around at, many of the LayoutTest flaky failures
> are timeout-related. There's something in the test harness and web
> server configurations that cause tests to be unpredictably slower. I
> don't think Apple has this problem, and I think that's because they
> use the built in apache instance in OS X, and also because they have a
> very different model for test execution (how we run tests in
> parallel). This is pure speculation, though, and I'm sure some of the
> more senior people on the team can correct me or add more.
>
> -- Dirk
>
>
> On Tue, Sep 8, 2009 at 5:14 PM, Pawel Hajdan wrote:
> > I'm trying to understand why some layout tests are flaky. Does WebKit
> have
> > the same problem? When I visit build.webkit.org something is always red,
> so
> > it may be flakiness.
> > What are the most common causes of layout tests failures for Chromium?
> Flaky
> > crashes seem to be especially weird.
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Layout try slaves

[David Levin]

But the canaries are release so having debug for the try bots allows one to
find issues that the canaries don't catch with new webkit merges.
On Tue, Sep 1, 2009 at 4:39 PM, Jeremy Orlow  wrote:

> I'd suggest putting the webkit layout test slaves under release.  This
> would allow us to catch debug/release build errors (since the normal bots
> are on debug) and layout tests run MUCH faster under release.
>
>
> On Tue, Sep 1, 2009 at 8:47 AM, Marc-Antoine Ruel wrote:
>
>>
>> All try slaves are currently in debug.
>>
>> On Mon, Aug 31, 2009 at 4:15 PM, Julie Parent
>> wrote:
>> > Are these running release or dbg?
>> >
>> > On Mon, Aug 31, 2009 at 1:12 PM, Marc-Antoine Ruel > >
>> > wrote:
>> >>
>> >> On Mon, Aug 31, 2009 at 12:39 PM, Brett Wilson
>> wrote:
>> >> > On Mon, Aug 31, 2009 at 10:13 AM, Marc-Antoine Ruel<
>> mar...@chromium.org>
>> >> > wrote:
>> >> >>
>> >> >> If you are not a committer, you can skip this message.
>> >> >>
>> >> >> If you want to run layout tests as a try job, you can use the layout
>> >> >> try slaves. They are not in the default pool so you need to
>> reference
>> >> >> them manually.
>> >> >>
>> >> >> The format is:
>> >> >> gcl try foo --bot layout_win,layout_mac,layout_linux
>> >> >
>> >> > This is great. Is this documented anywhere? Seems like
>> >> > http://dev.chromium.org/developers/how-tos/webkit-merge-1 would be a
>> >> > very useful place to have it.
>> >>
>> >> I'm not a webkit gardener so I don't think I'm the best person to
>> >> modify this page with useful information.
>> >>
>> >> M-A
>> >>
>> >> >>
>> >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

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

[David Levin]

On Mon, Aug 24, 2009 at 1:37 PM, Dirk Pranke  wrote:

>
> On Mon, Aug 24, 2009 at 11:37 AM, Ojan Vafai wrote:
> > The end goal is to be in a state where we have near zero failing tests
> that
> > are not for unimplemented features. And new failures from the merge get
> > addressed within a week.
> > Once we're at that point, would this new infrastructure be useful? I
> > completely support infrastructure that sustainably supports us being at
> near
> > zero failing tests (e.g. the rebaseline tool). All infrastructure/process
> > has a maintenance cost though.
>
> True enough. There are at least two counterexamples that are worth
> considering. The first is that probably won't be at zero failing tests
> any time soon (where "any time soon" == next 3-6 months), and so there
> may be intermediary value. The second is that we have a policy of
> running every test, even tests for unimplemented features, and so we
> may catch regressions for the foreseeable future.
>
> That said, I don't know if the value will offset the cost. Hence the
> desire to run a couple of cheap experiments :)


What do the "cheap experiments" entail?  Key concern: If the cheapness is to
put more work on the webkit gardeners, it isn't cheap at all imo.



>
>
> -- Dirk
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] (Solution) Are you getting svn (or gclient sync) hangs on Windows Vista?

[David Levin]

Then, run this command (from an Administrator command prompt):
 netsh interface tcp set global autotuninglevel=disabled

Hopefully, it will be fixed for you as it seems to be for me.

Reference:
http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx
Dave

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Missing config.h?

[David Levin]

Plug: I believe check-webkit-style will ensure that it is there in cpp file
and not there in h files.
And yes, eventually this will likely be part of another tool so you get the
messages automatically when doing some step (like prepare-ChangeLog) but it
isn't yet.


On Fri, Aug 7, 2009 at 10:15 AM, Nate Chapin  wrote:

> Nitpick: Always include config.h in an implementation file, never in a
> header file.(http://webkit.org/coding/coding-style.html)
>
> ~Nate, who has gotten dinged in reviews repeatedly for that mistake.
>
>
> On Fri, Aug 7, 2009 at 10:10 AM, Dimitri Glazkov wrote:
>
>>
>> This is more of a WebKit-land question, rather than Chromium-land
>> question. And yes, it's basically a rule on WebKit-land -- always
>> include config.h.
>>
>> You may want to raise the idea of a presubmit check on webkit-dev.
>>
>> :DG<
>>
>> On Fri, Aug 7, 2009 at 5:48 AM, Ben Laurie wrote:
>> >
>> > I just got bitten by failing to
>> >
>> > #include "config.h"
>> >
>> > in a file. This caused that file to have a different version of KURL
>> > from the rest of the code (it did not use GOOGLEURL, whereas the rest
>> > did) with predictably bad results.
>> >
>> > I'm wondering whether either:
>> >
>> > a) Including config.h wherever its needed, or
>> >
>> > b) Having a test to check it is included spread about the place
>> >
>> > is a good idea? Certainly would've saved me some time.
>> >
>> > >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Quota UI for LocalStorage (and others in the future)

[David Levin]

On Wed, Jul 29, 2009 at 11:28 AM, Drew Wilson  wrote:

> I've been starting to lean in this direction as well. The problem is that
> extensions are currently not cross-platform and would require separate
> implementations for each platform. And in many cases the extension delivery
> mechanism is under the control of an arbitrary third party (i.e. Google,
> Mozilla, Apple, etc) who has control over which extensions can be hosted,
> which is not particularly "open-web"-by.
>

It seems that a good approach is to make as much of the api into html5 as
possible (like Shared Workers).  Then there could be a small bit that is
extension (platform) specific (making the Shared Worker a Persistent
Worker).  Then there is a small surface area which is not html 5.  This also
allows apps that to do a lot of things in a similar manner (even when they
don't get the extra permissions).

dave


>
> It might be a reasonable starting point, though, with the goal being to
> sort through the security and installation issues and eventually come up
> with a cross-platform API in a future HTML version.
>
> -atw
>
>
> On Wed, Jul 29, 2009 at 11:15 AM, Linus Upson  wrote:
>
>> I'm coming to the opinion that we should leverage the install mechanism of
>> the extension system for apps that need special permissions, increased
>> quotas, expanded lifetimes, etc. The extension can be almost vacuous, and in
>> our extension world exceptionally lightweight. It only needs to make the
>> special capability available to the page.
>> As Maciej brought up on the whatwg list, the extension system gives us 
>> multiple affirmative steps,
>> vetting, reputation and revocation. It also gives us a UI access point. All
>> of these are important for controlling apps that aren't safe and stateless.
>>
>> Linus
>>
>>
>> On Wed, Jul 29, 2009 at 10:24 AM, Ian Fette  wrote:
>>
>>> I would say that if all the browsers are doing 5MB fixed quota for local
>>> storage, it is a good way to start. Sadly, I think we need to start thinking
>>> about this now for databases though (certainly I don't want to hit yes 4,000
>>> times as my gmail syncs up to 20GB)
>>> 2009/7/29 Jeremy Orlow 
>>>
>>> On Wed, Jul 29, 2009 at 9:37 AM, Peter Kasting wrote:

> On Wed, Jul 29, 2009 at 12:39 AM, Ben Laurie  wrote:
>
>> That seems overly simplistic to me - for example, just because I
>> sometimes want to let a chat app have access to my camera, doesn't
>> mean I want it always to have access. Given the number of users I've
>> seen fix this problem with duct tape, I think I can conclude that
>> users would use controls if they had controls they understood and
>> trusted.
>>
>
> I don't agree.  I believe granularity is not only useless but harmful
> for the majority of users.  See user studies of desktop app install flows 
> or
> options dialogs that universally conclude that giving people more choices
> helps a small number of people and loses a large number.  This is the
> philosophy we designed Chrome around, so we're strong backers of it.
>

 I agree on principle.  I can imagine a couple ways the web app might
 state the capabilities it needs up front.  The problem is that, with newer
 "versions" of the application, the needs might change.  But how do we keep
 them from changing so often that the user just gets used to clicking 'yes'
 every time?  I can't think of any good solution for this.

 Anyway, I think we've gotten a bit abstract here.  It's good to talk
 about this in general, but in the mean time I'm not sure what to do for
 LocalStorage.

 Is the fixed quota per origin a good way to start?  If so, is the plan
 to leave it that way until someone tries to tackle this stuff in a more
 unified way?

 J



>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] auto-hide bookmarks bar

[David]

I hope it's ok to post this in this groupmy apologies if it's not.

I really like the fact that the bookmark bar is seen only in the new
tab page by default. Would it be possible to have the bookmark bar
become visible when you move over to the navigation bar at the top of
the screen. This would keep the screen decluttered by not showing the
bookmarks bar when you don't need it but at the same time a person
wouldn't have to go to the home page every time they wanted to access
their bookmarks. The auto-hiding feature would also be helpful when
toolbars are added to chrome as 3rd party toolbars would only be
visible when a person really needed them.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mozilla design challenge

[David Levin]

There is one internal site that I go to enter some feedback.  (It has auto
save now but didn't at one point.)
Recently I don't go there very often.  It is entirely possible (and
frequently happens) that I get interrupted while entering feedback and have
to look up other information (during which I look up information from lots
of sources).  Then I go back and expect my feedback to still be there.  I
would be highly annoyed at any browser that tossed my feedback (which takes
me a while to write).

An external example of this is the review tool for WebKit (which doesn't
have auto-save and doesn't have a manual draft save mode even).

dave


On Wed, Jul 22, 2009 at 9:54 AM, Linus Upson  wrote:

> With a good heuristic, I think it will be very unlikely that we'll kill a
> renderer that has useful state. What are the chances that a tab on a site
> that I don't go to often, and that I opened 30 tabs ago has js/dom state
> that is critical for me? Mobile browsers already euthanize unused
> tabs aggressively. Since so few users have 20+ tabs open at once perhaps we
> can just reset their expectations for what happens if they accumulate a
> large number of tabs. Perhaps the heuristic could be tied to the mythical
> great overflow UI. For all of these heavy users I suspect they would prefer
> chrome to remain zippy fast with large tab sets rather than paging a
> renderer that 99.9% of the time doesn't have any interesting state.
> Linus
>
>
> On Tue, Jul 21, 2009 at 2:03 PM, Scott Hess  wrote:
>
>>
>> I don't think it's reasonable to require the user to specify which
>> tabs to suspend, except, perhaps, if we develop a metric for
>> power-hungry tabs and expose that.
>>
>> I think there is some potential for UI geared towards particular
>> use-cases which could be overloaded to also allow more aggressive
>> suspend.  For instance, WRT my earlier posting, I would expect my
>> pinned tabs to be given stronger priority, and my on-deck-to-read tabs
>> to be treated more like preloaded/rendered bookmarks.  There could be
>> other UI advantages in there, like the on-deck tabs for a particular
>> project could group under a single tab with other UI widgets to select
>> which document within the group.
>>
>> -scott
>>
>>
>> On Tue, Jul 21, 2009 at 1:50 PM, Ryosuke Niwa wrote:
>> > Is it possible to provide an intuitive UI that allows users to choose
>> which
>> > tabs to be suspended?
>> > For example, just like users can click buttons on taskbar to pop up a
>> > particular window, we could provide a small window that pop-in tabs /
>> > windows.  And then we can suspend all windows / tab that
>> are popped into.
>> > Ryosuke
>> >
>> > On Tue, Jul 21, 2009 at 9:32 AM, Erik Kay  wrote:
>> >>
>> >> You may be on to something, but I think it's more complex than this.
>>  For
>> >> example bookmark systems don't work because people use them for a
>> number of
>> >> conflicting purposes (my list of things to read every day, a simple
>> history
>> >> system, a 'to read' list, a collection of links for research), which
>> have
>> >> different UI requirements.  I think the same thing has happened with
>> tabs
>> >> (and there's a surprising amount of overlap).  Here are the use cases I
>> know
>> >> I wind up using:
>> >> - a few long running apps that need to keep running, potentially
>> notifying
>> >> me of new events (calendar, mail, chat, buildbot, etc.)
>> >> - a few pages that I'm currently actively using (a screenshot from a
>> bug
>> >> I'm looking at, some reference documentation, a writely page I'm
>> editing
>> >> between compiles, etc.)
>> >> - a "to read" list of pages that I started reading but didn't finish
>> yet
>> >> (sometimes this is a collection of related pages when researching
>> something)
>> >> - I'm sure there are others.
>> >> In my use case, 80% of my tabs could easily be killed / suspended (or
>> even
>> >> hidden altogether) without any downside to me.  The problem is that
>> there
>> >> isn't a way to automatically figure out which ones are which.  Which
>> ones
>> >> have pending state that might be lost? (yes, some of this is bad app
>> design,
>> >> but there are many like this)  Which ones do I expect to keep running
>> all of
>> >> the time because of notifications?  What about that flash game that I
>> left
>> >> running in the background?
>> >> Maybe we could come up with some heuristics that could detect some of
>> this
>> >> automatically, but I worry that there will be so many exceptions that
>> it
>> >> won't work.  That means we'd need to come up with a better UI to
>> express
>> >> these concepts where the user chose to treat tabs differently in some
>> >> explicit way.  There are a number of extensions that try to do this for
>> some
>> >> specific use cases (to read lists, pinned tabs, etc.).  I'm not sure
>> that
>> >> these are better than bandaids though.
>> >> Erik
>> >>
>> >> On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee 
>> wrote:
>> >>>
>> >>> I feel like people are using tabs as

[chromium-dev] Re: V8 bindings are now fully upstreamed!

[David Levin]

Woohoo

On Fri, Jul 17, 2009 at 10:42 AM, Nate Chapin  wrote:

>
> As of r20923, src/webkit/port/ has been deleted and the last of the V8
> bindings are living in svn.webkit.org.  There's still some cleanup of
> the bindings to be done, but they are all upstream now.  Hopefully
> this will make everyone's life a little easier.
>
> If you're reading this email, you probably deserve thanks for one or
> more of the following reasons:
> * You authored a V8 binding upstreaming patch
> * You reviewed a V8 binding upstreaming patch
> * You suffered through an extended build breakage caused by a V8
> binding upstreaming patch
>
> Thanks!
> ~Nate
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: base::string16 / WebCore::String incompatibility

[David Levin]

On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher  wrote:
>
>
> WebString exists (has for many moons now).  It is just a wrapper for
> StringImpl,
> the same way WebCore::String is.  It is not threadsafe due to the reference
> counting done for StringImpl.
>

fwiw, I've checked in all the mechanics to do cheaply use StringImpl's
across threads.

You have to call a method (to be named) and then you'll get back a new
StringImpl which uses the *same underlying buffer *and can be passed to
another thread. (Right now, webkit code calls StringImpl::copy() for this
purpose but that allocates a new buffer and copies the contents there. I
can't modify that method due to the fact that it is currently a threadsafe
call and that is relied on in some places in webkit.)

Let me know if you want/need more details about it.

Dave


 That makes it a very bad candidate for serializing
> via Chrome IPC.  Someone might naively handle such an IPC on the IO thread,
> and then PostTask the WebString to another thread.  We could try to solve
> that
> using assertions, but I decided instead to avoid serializing non-POD WebKit
> API
> types over Chrome IPC.
>
> For reference:
>
> http://src.chromium.org/viewvc/chrome/trunk/src/webkit/api/public/WebString.h?view=markup
>
> -Darin
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: some questions about chrome's layout-test

[David Jones]

Ok, let me make question simple.
 
I get some ERRORs on my DOS while running layout-test, such as :
 
090706 15:37:19 __init__.py:1032 ERROR 
LayoutTests/fast/backgrounds/svg-as-mask.html failed:
  Text diff mismatch
  Image mismatch
 
These ERRORs are made of two kinds: expected and unexpected, the unexpected 
ERRORs will be counted as the final number in :
 
090706 15:44:24 __init__.py:1032 INFO Exit status: 9

right??
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: expected chromium changes for Chrome OS support

[David Moore]

brave is between boring and broken

On Wed, Jul 8, 2009 at 3:48 PM, Peter Kasting wrote:
> On Wed, Jul 8, 2009 at 3:45 PM, Scott Violet  wrote:
>>
>> While you can certainly build this configuration on Linux
>> now, running it outside of Chrome OS isn't particularly interesting.
>
> (Since I was curious, I asked more about this)
> In particular, this configuration makes use of communications to/from the
> windowmanager that only exist with the Chrome OS windowmanager.  Running it
> under a different window manager would be somewhere between boring and
> broken.
> PK
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: some questions about chrome's layout-test

[David Jones]

>See the expectations file, it lists the ones that are known to fail on a 
>>given platform.  This is how we easily track new failures.
Most of the ERRORs I get such as :
 
090706 15:37:19 __init__.py:1032 ERROR 
LayoutTests/fast/backgrounds/svg-as-mask.html failed:
  Text diff mismatch
  Image mismatch
 
are just an ERROR that is to be expected, so they are not included in the final 
summary, which means not included in the final regression errors: 
 
090706 15:44:24 __init__.py:1032 INFO Exit status: 9
 
right?
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: cygwin dependence missing?

[David Jones]

>Okay, I think I've figured this out and it's a relatively undocumented
>aspect of our win builds (from what I can tell).
>
>The third_party/cygwin install we have has a modified version of
>cygwin1.dll , which has been patched to tell cygwin the root is
>third_party/cygwin rather than /. In order for this to work correctly,
>you need to run third_party/cygwin/setup_mount.bat to stuff the right
>entries into the registry.
>
>We should probably change run_layout_tests to automatically run this
>script prior to running the regression (running it every time should
>be harmless).
>
>-- Dirk

Do you mean my layout-test actually uses the cygwin under depot_tools, but not 
the third_party/cygwin?
also, what does setup_mount.bat  do?
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: some questions about chrome's layout-test

[David Jones]

>It means those two tests failed to produce the expected results.  When >done, 
>the summary page should open with a list of any tests that didn't >result in 
>the expected way, with links to see the expected, actual and >difference in 
>values.
 
really? While runing layout-test, I always get a lot of ERRORs. But at the end, 
I get a summary as :
Expected to fail, but passed (5):
  LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html
  LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html
  LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html
  LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html
  LayoutTests/fast/encoding/invalid-UTF-8.html
Expected to timeout, but passed (1):
  LayoutTests/http/tests/security/credentials-in-referer.html
Regressions: Unexpected failures (8):
  LayoutTests/fast/css/css2-system-fonts.html = FAIL
  LayoutTests/fast/dom/anchor-toString.html = FAIL
  LayoutTests/fast/dom/java-applet-calls.html = FAIL
  LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL
  LayoutTests/http/tests/security/cross-frame-access-protocol-explicit-domain.ht
ml = FAIL
  LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL
  LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL
  LayoutTests/plugins/embed-attributes-setting.html = FAIL
Regressions: Unexpected timeouts (1):
  LayoutTests/http/tests/security/originHeader/origin-header-for-https.html = 
TIMEOUT
--
=> Tests to be fixed for the current release (786):
88 test cases (11.2%) Passed
364 test cases (46.3%) Skipped
287 test cases (36.5%) Text diff mismatch
190 test cases (24.2%) Simplified text diff mismatch
160 test cases (20.4%) Image mismatch
10 test cases (1.3%) Test timed out
6 test cases (0.8%) Test shell crashed
2 test cases (0.3%) No expected image found
=> Tests we want to pass for the current release (8984):
8273 test cases (92.1%) Passed
364 test cases (4.1%) Skipped
299 test cases (3.3%) Text diff mismatch
200 test cases (2.2%) Simplified text diff mismatch
164 test cases (1.8%) Image mismatch
11 test cases (0.1%) Test timed out
6 test cases (0.1%) Test shell crashed
2 test cases (0.0%) No expected image found
=> Tests to be fixed for a future release (0):
=> All tests (10884):
8752 test cases (80.4%) Passed
2130 test cases (19.6%) Skipped
409 test cases (3.8%) Text diff mismatch
301 test cases (2.8%) Simplified text diff mismatch
183 test cases (1.7%) Image mismatch
12 test cases (0.1%) Test timed out
6 test cases (0.1%) Test shell crashed
2 test cases (0.0%) No expected image found

090706 15:44:24 __init__.py:1032 INFO Exit status: 9
090706 15:44:24 __init__.py:1032 INFO flushing stdout
090706 15:44:24 __init__.py:1032 INFO flushing stderr
090706 15:44:24 __init__.py:1032 INFO stopping http server
090706 15:44:24 __init__.py:1032 INFO Shutting down http server
 
I think that means only 9 ERRORs should happen. Is that a contradiction?
puzzled..
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] some questions about chrome's layout-test

[David Jones]

I have worked on webkit ,though I didn't know much about wekkit's layout-test. 
I'm curious about chrome's layout-test.
-do you take webkit's layout-test into chrome with any changes? I don't think 
so, so what're these changes?
-why simutaneously run 2 test_shell ?  for efficiency?
-while I'm runing run_webkit_test.bat, my DOS always display ERROR as below:
090706 15:37:19 __init__.py:1032 ERROR 
LayoutTests/fast/backgrounds/svg-as-mask.html failed:
  Text diff mismatch
  Image mismatch
090706 15:37:20 __init__.py:1032 ERROR
LayoutTests/fast/block/float/013.html failed:
  Text diff mismatch
  Image mismatch
090706 15:37:21 __init__.py:1032 ERROR 
LayoutTests/fast/block/float/nested-clearance.html failed:
  Text diff mismatch
  Image mismatch

What does that mean? 
Which __init__.py does it use? I find a lot of __init__.py under chromium

 
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: cygwin dependence missing?

[David Jones]

That's really weird, as I posted, between the two same layout-tests, one 
succeeded on XP of my notebook, one failed on XP of my PC.
I totally agree with you, I think that must be something wrong about 
ENVIROMENT, such as PATH.
 
FYI:
my PATH=D:\Program Files\Perl\bin;D:\Program 
Files\Perl\site\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;D:\Program
 Files\Rational\common;D:\Program 
Files\Rational\ClearCase\bin;C:\Python24;C:\Python24\Scripts;D:\depot_tools;

 
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: cygwin dependence missing?

[David Jones]

Well,new headway is I found it's really a weird bug. I copies the same source 
from my pc to my notebook(both are Windows XP), and run layouttest.
 
The one on pc is still with the cygwin errors I've posted, but the notebook's 
succeeded without any cygwin error.
 
I cann't explain that, could anyone explain that?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: cygwin dependence missing?

[David Jones]

>I wasn't either, but a simple search provided this:

>:: Set CYGWIN variable to 'nontsec'. That makes sure that permissions
>:: on your windows machine are not updated as a side effect of cygwin:: 
>>operations.SET CYGWIN=nontsec
 
well, where to set it? in the run_webkit_tests.bat?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: cygwin dependence missing?

[David Jones]

>It looks like it had trouble writing to /tmp.  I don't think there are 
>>missing binaries, looks like a space/permission issue.  Is there enough 
>>space available?

hi,John. I run it on Windows XP, and I'm very sure the space is enough.

>set CYGWIN=nontsec
>?

hi,Marc. What's it? I'm not familiar with cygwin, in fact.




--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] clean build needed on Windows and Linux after your next sync

[David Levin]

Due to idl change.
OSX seems to pick up the change fine without the need for a clean build.
Thanks,
Dave

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] cygwin dependence missing?

[David Jones]

I reviewed my layout-tests' output, and found some errors like:
090629 14:28:30 __init__.py:1032 ERROR 
LayoutTests/http/tests/xmlhttprequest/xml-encoding.html failed:
  Text diff mismatch
  Simplified text diff mismatch
/cygdrive/e/mychromesrc/src/third_party/cygwin/bin/wdiff: /tmp/t101c.0: No such 
file or directory
 
I think I missed something about cygwin, right?
How to make up?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: MYTH: WebKit uses design docs

[David Levin]

It seems like if you are doing a significant change to an existing area or
adding a feature, it is good to explain the change that you're planning to
do (and hopefully get input from whoever had been working on that area
recently the most).  This explanation doesn't have to be
a "design doc" though.

For example from bug https://bugs.webkit.org/show_bug.cgi?id=25463,

"The comments in the bug seem to show a lack of consensus as to whether we
want
this feature and whether the API is appropriate. *These design issues should
be**
**hashed out (perhaps on the mailing list) before submitting a patch for
code review.*"


Dave

On Mon, Jun 29, 2009 at 10:22 AM, Eric Seidel  wrote:

>
> It seems to be a common misconception of Google engineers joining
> WebKit that WebKit expects design docs like Google does.
>
> I see Google writing design docs a lot.  I saw one or two in my 3
> years at Apple.  I've never seen WebKit use them.
>
> Google engineers posted 3 design docs to webkit-dev last week.  I
> doubt any of those docs will get much feedback, but I could be wrong.
>
>
> And then this response today:
>
> On 2009-06-29, at 02:05, Johnny Ding wrote:
>
> > It will be better to send out detail explanation/design doc before
> sending patches if the changes are big:)
>
> Since when has writing a design document been part of the process of
> contributing to WebKit?
>
> - Mark [Rowe]
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] tests_expectations.txt

[David Jones]

In http://dev.chromium.org/developers/testing/webkit-layout-tests, it's wrote:
 
Tests marked as SKIP in 
webkit/tools/layout_tests/test_lists/{mac,win}/tests_fixable.txt or 
tests_ignored.txt won't be run at all, generally because they cause some 
intractable tool error. To force one of them to be run, either rename that file 
or specify the skipped test as the only one on the command line (see below).

But in my chromium source, I didn't find a tests_fixable.txt or 
tests_ignored.txt, but a test_expectations.txt.
Is that a carelessness while writing "WebKit Layout Tests"??

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

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

[David Jones]

Well , I reviewed my layout-tests' output again, and found some errors like:
090629 14:28:30 __init__.py:1032 ERROR 
LayoutTests/http/tests/xmlhttprequest/xml-encoding.html failed:
  Text diff mismatch
  Simplified text diff mismatch
/cygdrive/e/mychromesrc/src/third_party/cygwin/bin/wdiff: /tmp/t101c.0: No such 
file or directory

I think I missed something, right?
 
 
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

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

[David Jones]

I have ran layouttests on Windows XP, and got a result as:
Expected to fail, but passed (5):
  LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html
  LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html
  LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html
  LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html
  LayoutTests/fast/encoding/invalid-UTF-8.html
Expected to timeout, but passed (1):
  LayoutTests/http/tests/security/credentials-in-referer.html
Regressions: Unexpected failures (8):
  LayoutTests/fast/css/css2-system-fonts.html = FAIL
  LayoutTests/fast/dom/anchor-toString.html = FAIL
  LayoutTests/fast/dom/java-applet-calls.html = FAIL
  LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL
  LayoutTests/http/tests/security/cross-frame-access-protocol-explicit-domain.ht
ml = FAIL
  LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL
  LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL
  LayoutTests/plugins/embed-attributes-setting.html = FAIL
Regressions: Unexpected timeouts (1):
  LayoutTests/http/tests/security/originHeader/origin-header-for-https.html = TI
MEOUT
--
=> Tests to be fixed for the current release (786):
86 test cases (10.9%) Passed
364 test cases (46.3%) Skipped
289 test cases (36.8%) Text diff mismatch
191 test cases (24.3%) Simplified text diff mismatch
160 test cases (20.4%) Image mismatch
11 test cases (1.4%) Test timed out
6 test cases (0.8%) Test shell crashed
2 test cases (0.3%) No expected image found
=> Tests we want to pass for the current release (8984):
8271 test cases (92.1%) Passed
364 test cases (4.1%) Skipped
301 test cases (3.4%) Text diff mismatch
201 test cases (2.2%) Simplified text diff mismatch
164 test cases (1.8%) Image mismatch
12 test cases (0.1%) Test timed out
6 test cases (0.1%) Test shell crashed
2 test cases (0.0%) No expected image found
=> Tests to be fixed for a future release (0):
=> All tests (10884):
8753 test cases (80.4%) Passed
2130 test cases (19.6%) Skipped
411 test cases (3.8%) Text diff mismatch
302 test cases (2.8%) Simplified text diff mismatch
183 test cases (1.7%) Image mismatch
13 test cases (0.1%) Test timed out
6 test cases (0.1%) Test shell crashed
2 test cases (0.0%) No expected image found
I don't know what it tells, am I passed the layouttests?
 
There's also a layouttests in webkit, what's the relation between chrome's 
layouttest and webkit's layouttest? I think webkit's layouttest only run on 
Leopard.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] why some chrome's tests fail?

[David Jones]

I get a new question here:
I've checked most of chrome's tests, and haven't find a RUN_ALL_TEST() which I 
think is necessary for GTest.
simply, the printing_unittests project.
 
why?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] why some chrome's tests fail?

[David Jones]

hi, pawel.
>It is a bit worrying to me to read "most of the tests fail". Do you
>encounter more failures?
Yes, about 40% of my chrome's tests(I mean the .exe of tests) fail. And my 
revision is r17306. I am wondering why, -_-!


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] [chromium-dev]RE: why some chrome's tests fail?

[David Jones]

hi,Evan
 
>You can comment it out and just run "gclient sync" again.  Not sure
>why you'd want to pass the --revision flag.
I just wanna use one fixed revision, don't wanna update it everyday. Take that 
into consideration, that's easy to fix problems.
>Some data used by tests is not in the public tree, as many (like
>performance tests) are attempting to test against real web sites and
>we can't republish their content.
while, that must be a bug of chrome's test. I copied the url:
file:///F:/chrometrunk/src/data/tab_switching/kannada.chakradeo.net/index.html
 from the url bar of chrome's tab_switching_test.exe, and chrome doesn't find 
that index.html. So I asked.


 
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] why some chrome's tests fail?

[David Jones]

I'm trying to run chrome's tests, but find lots of failures up there.
I wanna ask:
1. most of tests fail like below, why?
[--] Global test environment tear-down
[==] 42 tests from 8 test cases ran. (3984 ms total)
[  PASSED  ] 41 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] TextEliderTest.TestGeneralEliding
 1 FAILED TEST
  YOU HAVE 1 DISABLED TEST
2.I want to test webkit with its layouttest, but find 
"src/webkit/data/layout_tests/LayoutTests": None
in .gclient. If I comment it out and execute 
gclient sync --rivision s...@
Will I get the layouttest?
3.I think I miss some test data in my src, but I did get a completed "gclient 
sync" which I'm very sure. For exmaple, in tab_switching_tests, I can't find 
src/data/ directory which is a part of testing url:
file:///F:/chrometrunk/src/data/tab_switching/kannada.chakradeo.net/index.html

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Implementing an onidle event (and the Linux implications)

[David Levin]

That file has been deleted from gears -- not as a reflection on the
implementation but due to the lack of its use in gears.
2009/5/7 Evan Martin 

>
> Does this mean PhistucK could just rely on the gears implementation?
> Then it would require no Chrome changes.
>
> 2009/5/7 David Levin :
> > fwiw, gears had an implementation that didn't depend
> > on XScreenSaverQueryInfo
> >
> http://code.google.com/p/gears/source/detail?r=2641&path=/trunk/gears/notifier/user_activity.cc
> > see user_activity_linux.cc
> >
> > 2009/5/7 Adam Barth 
> >>
> >> I'd encourage you to implement it for extensions first.  It seems
> >> really useful for queuing up notifications, etc.
> >>
> >> Adam
> >>
> >>
> >> 2009/5/7 PhistucK :
> >> > (Creating a new thread for it.)
> >> > So, I started looking into it.
> >> > And as you wrote, in order to implement this function for all of the
> >> > platforms (is it even logical to implement a feature like an event
> only
> >> > for
> >> > certain platforms?), I will need to set the ENABLE_XSS_SUPPORT to 1
> >> > (like
> >> > the comment there says).
> >> > I just want to know whether I am wasting my time here, or it can
> really
> >> > be
> >> > taken into consideration.
> >> > Now, Aaron suggested it might be a good idea to use the Extensions
> >> > system as
> >> > a playground for new features such as this one, so I thought about
> >> > implementing it as "chrome.onsystemidle". Does this make sense?
> >> > acceptable?
> >> > other suggestions?
> >> > ☆PhistucK
> >> >
> >> >
> >> > 2009/5/6 Evan Martin 
> >> >>
> >> >> base/idle_timer implements this.  The only implementation detail
> would
> >> >> be exposing it to JS.
> >> >>
> >> >> It would also make us depend on xscreensaver on Linux which is :( but
> >> >> whatever.
> >> >>
> >> >> 2009/5/6 PhistucK :
> >> >> > One more thing - are you planning to implement a function that will
> >> >> > return
> >> >> > the status of the machine?
> >> >> > For presence information, I want to know if the computer is idle
> and
> >> >> > if
> >> >> > it
> >> >> > does, I do not want to signal the presence. Say, during screen
> saver
> >> >> > or
> >> >> > when
> >> >> > the screen is shut down (through windows and its power management
> >> >> > system,
> >> >> > obviously, not through the shut down button :)).
> >> >> > And if you were not planning on it - is it so easy to implement
> that
> >> >> > you
> >> >> > will implement it in a few seconds? ;)
> >> >> > I wish I knew C++ (and had enough disk space :( really low now), I
> >> >> > would
> >> >> > have tried to implement it by myself or help a little with
> >> >> > everything.
> >> >> > :)
> >> >> >
> >> >> > ☆PhistucK
> >> >
> >> > >
> >> >
> >>
> >> >>
> >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Implementing an onidle event (and the Linux implications)

[David Levin]

fwiw, gears had an implementation that didn't depend
on XScreenSaverQueryInfo

http://code.google.com/p/gears/source/detail?r=2641&path=/trunk/gears/notifier/user_activity.cc

see user_activity_linux.cc


2009/5/7 Adam Barth 

>
> I'd encourage you to implement it for extensions first.  It seems
> really useful for queuing up notifications, etc.
>
> Adam
>
>
> 2009/5/7 PhistucK :
> > (Creating a new thread for it.)
> > So, I started looking into it.
> > And as you wrote, in order to implement this function for all of the
> > platforms (is it even logical to implement a feature like an event only
> for
> > certain platforms?), I will need to set the ENABLE_XSS_SUPPORT to 1 (like
> > the comment there says).
> > I just want to know whether I am wasting my time here, or it can really
> be
> > taken into consideration.
> > Now, Aaron suggested it might be a good idea to use the Extensions system
> as
> > a playground for new features such as this one, so I thought about
> > implementing it as "chrome.onsystemidle". Does this make sense?
> acceptable?
> > other suggestions?
> > ☆PhistucK
> >
> >
> > 2009/5/6 Evan Martin 
> >>
> >> base/idle_timer implements this.  The only implementation detail would
> >> be exposing it to JS.
> >>
> >> It would also make us depend on xscreensaver on Linux which is :( but
> >> whatever.
> >>
> >> 2009/5/6 PhistucK :
> >> > One more thing - are you planning to implement a function that will
> >> > return
> >> > the status of the machine?
> >> > For presence information, I want to know if the computer is idle and
> if
> >> > it
> >> > does, I do not want to signal the presence. Say, during screen saver
> or
> >> > when
> >> > the screen is shut down (through windows and its power management
> >> > system,
> >> > obviously, not through the shut down button :)).
> >> > And if you were not planning on it - is it so easy to implement that
> you
> >> > will implement it in a few seconds? ;)
> >> > I wish I knew C++ (and had enough disk space :( really low now), I
> would
> >> > have tried to implement it by myself or help a little with everything.
> >> > :)
> >> >
> >> > ☆PhistucK
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Unforking: Canary Bot Lives!

[David Levin]

On Fri, May 1, 2009 at 3:38 PM, John Abd-El-Malek  wrote:

> This is definitely awesome!
> Too bad, I was just about to sign up to do the next n merges ;)
>

Dimitri, it sounds like John wants to be a webkit build sheriff :) (the
evolution of the merger roll).



>
>
> On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote:
>
>>
>> Hello all,
>>
>> This is kind of a momentous occasion. For the first time -- ever, our
>> WebKit Canary bot (the one that pulls directly from WebKit upstream)
>> has built successfully and was able to run tests:
>>
>>
>> http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20(webkit.org)/builds/2937
>>
>> What does this mean? This means that our unforking efforts have
>> finally paid off -- we can now pull directly from WebKit upstream!
>>
>> Congratulations to all of you who worked and helped during the last 7
>> months! This was a long run, and despite various setbacks, we have
>> reached this milestone.
>>
>> This also means that the daily merge as we know it is soon to be
>> replaced with a less daunting activity -- WebKit gardening. I am
>> working on the document to define what this will entail. Stay tuned.
>>
>> :DG<
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] unforking: 20% perf hit for international page cycler expected soon

[David Levin]

One of the few remaining forks is in
WebCore/platform/graphics/FontCache.cpp
(https://bugs.webkit.org/show_bug.cgi?id=21451).

I'll be checking in a change to remove this fork and as such we should
expect ~20% perf hit for the international page cycler.  The
internatonal page cycler test intentionally uses more fonts than users
are likely to use, so the perf hit isn't something that users would
notice in browsing scenarios.

Dave

PS Here's the code review url: http://codereview.chromium.org/100276

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Unforking: Canary Bot Lives!

[David Levin]

Awesome!  This is a really cool.

On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote:

>
> Hello all,
>
> This is kind of a momentous occasion. For the first time -- ever, our
> WebKit Canary bot (the one that pulls directly from WebKit upstream)
> has built successfully and was able to run tests:
>
>
> http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20(webkit.org)/builds/2937
>
> What does this mean? This means that our unforking efforts have
> finally paid off -- we can now pull directly from WebKit upstream!
>
> Congratulations to all of you who worked and helped during the last 7
> months! This was a long run, and despite various setbacks, we have
> reached this milestone.
>
> This also means that the daily merge as we know it is soon to be
> replaced with a less daunting activity -- WebKit gardening. I am
> working on the document to define what this will entail. Stay tuned.
>
> :DG<
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some "browser helper" process

[David Levin]

I think how to split/refactor depends on the feature, understanding the
current code, and working with the appropriate webkit dev.
For workers, we thought about how/where it made sense to split the impl for
chrome and talked with a...@webkit about it.  There was some iteration as we
figured out things better and as he made suggestions and it has worked out
fine so far.


On Wed, Apr 29, 2009 at 11:49 AM, Michael Nordman wrote:

>
> +chromium-dev
>
> Designing things in this front/back fashion and re-using the code
> entirely in chrome removes at least one high-coefficient of friction
> surface rubbing between the chromium and webkit teams. We will likely
> pay a higher price up front, but it should pay dividends down the
> road. Add an interesting feature and iphone, andriod, chrome, and
> safari all pick it up.
>
> I'm worried about the logistics of pulling this off for the appcache
> given the existing impl is live and in use in iphone and safari and
> soon andriod. We're talking about 'refactoring' or 'replacing'
> existing impls with new ones that support a remote backend. How can we
> reduce the upfront cost?
>
> * maybe build these new impls out in webcore w/o disrupting the existing
> impl
> * use the new impl for chrome (and any other webkit consumer that
> wishes to compile the new impls in would be free to do so)
> * somewhere down the road, deprecate the existing impl in favor of the
> new impl in webcore
>
> We haven't talked to the webkit guys about logistics like this, no
> data on where their head is?
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some "browser helper" process

[David Levin]

On Wed, Apr 29, 2009 at 7:02 AM, Peter Kasting wrote:

> On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow  wrote:
>
>> Darin was there on that lunch and was actually the one who first suggested
>> running parts of WebCore in the browser to me during a 1:1.  :-)
>>
>
> Indeed, we're already planning to do it in other ways -- using a text field
> as a directly-instantiable class in the UI, for example.
>
> I don't really have much of an opinion on this discussion except that I'm
> not so negative about the original plan of writing our own backend as Jeremy
> is.  Here are his objections: "From a technical standpoint, it's unclear
> how testing would work since our test_shell would be testing a different
> backend from what's in Chromium. It also means we have more code to
> maintain, and that code is completely off of WebKit's radar. It also makes
> Apple mad and Dimitri sad. So really, this doesn't seem like a good
> solution."
>
> I'm not sure how test_shell matters w.r.t. testing this backend, since the
> primary test of the backend (and the frontend?) would presumably be through
> unittests (w/mocks where necessary), which test the code directly and don't
> care what backend it's in. test_shell already doesn't have the same code as
> the main browser for 100 other things.
>
> Having code to maintain off WebKit's radar is again not a new situation.
> I'm not talking about forked stuff, just anything that isn't in WebKit.
> Having the code in WebKit is a two-edged sword, since when it's there it's
> gatekeepered on WebKit code review (not a big problem anymore since we have
> a couple reviewers now) and the WebKit community doesn't seem to try to keep
> their tree green. So IMO having code in WebKit is still just as much of a
> maintenance burden on us except with the additional hurdle that it's not in
> our direct tree.
>
> As far as making people mad, feh. Let's decide the right implementation
> first.
>

"making people mad" is a simplification of a complex set of things.

Ideally, there would be one implementation in webkit for html features which
would allow multiple things:
1. Better compatibility across webkit impls.  This makes it easier for web
devs.
2. Bugs fixes in one implementation help for both.
3. It helps move the web forward better because we may implement a feature
and our webkit impls will get it.
4. The above means that we can make better use of layout tests both in
knowing that the ones there should probably pass and contributing new ones
too.
5. Giving back to the webkit community is a good thing.
etc.


> But even if the original plan is IMO not so bad, I'm not opposed to the new
> plans either. People like Darin are much more qualified to comment on what
> would be *best* and I will be OK with whatever gets decided.
>
> PK
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

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

[David Levin]

On Thu, Apr 9, 2009 at 9:11 AM, Thomas Van Lenten wrote:

> fyi -Some failures will happen on the Macs because test_shell sets/restores
> user settings on startup/shutdown, so having more then one running can cause
> things to fail as one exits changing state on another that's running.  It's
> on my list to move into a helper app so it can be done around the whole
> setup instead, it just hasn't bubble up in the priority list yet.
>

When/If you do this, if you did it in WebKitTools, it would
awesome.



> TVL
>
>
>
> On Thu, Apr 9, 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.
>>>> Please keep an eye out over the next couple days for test flakyness that 
>>>> may
>>>> have resulted from this.
>>>>
>>>
>>> Nice job!
>>>
>>>
>>>>
>>>> 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 remaining obvious things we could do to make a significant
>>>> performance improvement:
>>>>
>>>> 1. Test and turn on parallelizing for Debug builds
>>>> 2. Get 4 or 8 core webkit buildbots
>>>> 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to
>>>> reduce test flakiness, we bucket tests by directory and run all those tests
>>>> in the same process (thanks to dlevin for this idea!). The problem is that
>>>> we're left with two very large buckets that can be further broken down. The
>>>> work of breaking them down further is trivial (just add the directory names
>>>> to a list in run_webkit_tests.py), the bigger problem is that some 
>>>> flakiness
>>>> starts to appear in the fast/http tests when we break them down further. 
>>>> So,
>>>> we need people to figure out what the source of the flakiness is and deal
>>>> with it appropriately.
>>>>
>>>
>>> For #3, an alternative may be to sort "http" tests to be first and don't
>>> break it down further. ("http" is less than one quarter of the time on OSX
>>> at least, so you can still scale up to quad core.)  Also, I think fast (and
>>> dom) can be broken down into the 1st sub dir level without increased
>>> flakiness.
>>>
>>> So this may be an easy gain without having to figure out lots of test
>>> depedencies (which can be a bit painful).
>>>
>>
>>
>> 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 launches a fresh test_shell for each test; and
>> --num-test-shells, which sets how many test_shell threads to run at once.
>> It'll be time-consuming (--run-singly is especially slow), and there will be
>> some work involved in comparing the results to figure out which test(s) are
>> causing problems, but it would be a valuable thing. And no programing
>> knowledge required.
>>
>> - Pam
>>
>>
>>
>>>  If we did all of the above, I expect we would see at least another
>>>> factor of two performance improvement.
>>>>
>>>> Let me know if you want to help out with any of this.
>>>>
>>>> Ojan
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

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

[David Levin]

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. Please
> keep an eye out over the next couple days for test flakyness that may have
> resulted from this.
>

Nice job!


>
> 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 remaining obvious things we could do to make a significant
> performance improvement:
>
> 1. Test and turn on parallelizing for Debug builds
> 2. Get 4 or 8 core webkit buildbots
> 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to
> reduce test flakiness, we bucket tests by directory and run all those tests
> in the same process (thanks to dlevin for this idea!). The problem is that
> we're left with two very large buckets that can be further broken down. The
> work of breaking them down further is trivial (just add the directory names
> to a list in run_webkit_tests.py), the bigger problem is that some flakiness
> starts to appear in the fast/http tests when we break them down further. So,
> we need people to figure out what the source of the flakiness is and deal
> with it appropriately.
>

For #3, an alternative may be to sort "http" tests to be first and don't
break it down further. ("http" is less than one quarter of the time on OSX
at least, so you can still scale up to quad core.)  Also, I think fast (and
dom) can be broken down into the 1st sub dir level without increased
flakiness.

So this may be an easy gain without having to figure out lots of test
depedencies (which can be a bit painful).



> If we did all of the above, I expect we would see at least another factor
> of two performance improvement.
>
> Let me know if you want to help out with any of this.
>
> Ojan
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: In process browser tests and singleton shutdown.

[David Levin]

On Sat, Apr 4, 2009 at 1:00 PM, Mike Belshe  wrote:

>
> Incidentally, when looking at Apple's webkit build, I noticed that their
> compiles will fail if new statics are introduced.  I assume this is for
> performance reasons, but maybe it's because webkit needs to be embedded in
> other systems and statics make that difficult.
>

fwiw, I thought it would be interesting to dig up some history on this, and
you pretty much got it:

   1. They avoid statics because "it would require WebKit to have a static
   initialization routine Such a routine increases the start-up time and
   memory footprint of anything that links against WebKit, which includes just
   about everything that ships with OS X." --
   https://lists.webkit.org/pipermail/webkit-dev/2006-June.txt
   2. They leak for perf reasons and because it caused issues in one case
   when the destructors were called on the main thread while another thread was
   using the objects --  https://bugs.webkit.org/show_bug.cgi?id=21810

Dave

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

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

[David Levin]

We could go with option 3 until someone is annoyed enough by the overhead to
write a script. :)


On Tue, Mar 24, 2009 at 4:19 PM, Ojan Vafai  wrote:

> OK. So, what I'm hearing is that every test should have a bug assigned to
> it, no matter the priority. In that case, there's a couple other options.
>
> *Option 3*
> Get rid of DEFER and don't add priorities to the test list. Instead require
> that every test have an associated bug (multiple tests can share a bug) and
> rely on the bug priority/owner to figure out when the test needs fixing and
> who is responsible for fixing it.
> Pros:
> -Works with our current bug triage process (kind of)
> -Makes for one easy place that people need to look for their todo list (the
> google code issue tracker)
> Cons:
> -Overhead of filing and closing bugs when the common case is just a
> rebaseline anyways
> -Hard to triage layout tests without understanding what's wrong with them
>
> *Option 4*
> Same as option 3, except we have a script that monitors the test list and
> automatically files a bug whenever a new test appears. The subject of the
> test is just the path listed in the test list, so the test can be found by
> searching the issue tracker. Similarly, when a test is removed from the test
> list, the bug is automatically closed.
>
> This has the same pros and cons as option 3 except that it totally removes
> the overhead associated with having a bug for each test path. Also, this
> would require someone to write the script to do this.
>
> Ojan
>
> On Tue, Mar 24, 2009 at 12:31 PM, David Levin  wrote:
> > I like this proposal.  I would also like a bugs for P3 which could
> explain
> > why it is a P3.  If is it an unimplemented feature, then all tests for
> that
> > unimplemented feature could have the same bug.
> > (Since I do merges and took a while to layout test file bugs from that) I
> > like option 2.  BUT I'm concerned that adding someone's email address to
> > test_fixable will not get any attention.  Right now, when you file a bug,
> > people get email and the bugs seem to be followed up.
> >
> > BUGS/PRIORITY TRIAGING
> > Option 1
> >
> > Addition Pro
> >
> > Email sent about new bug alerts people to the new issue -- I suppose one
> > could email people separately when adding their email address to
> > test_fixable (but this step could easily be missed).
> >
> > Dave
> >
> >
> > On Tue, Mar 24, 2009 at 12:14 PM, Marc-Andre Decoste 
> > wrote:
> >>
> >> I personally prefer having a bug assigned for the layout tests that we
> >> want to be fixed soon... 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 sort of dashboard for this, we could add a page 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:
> >>>
> >>> 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 spreadsheet to take ownership
> of
> >>> layout tests and just put our names directly in the test list? This
> seems
> >>> way more intuitive to me and avoids needing to look at multiple
> locations
> >>> for the state of the layout tests. I like having a read-only dashboard
> that
> >>> present this information in a useful way like the spreadsheet currently
> >>> does, but there should only be one place we modify.
> >>> BUGS/PRIORITY TRIAGING
> >>> Option 1
> >>> Every P0/P1/P2 test is required to have a bug id associated with it.
> New
> >>> failures get the UNTRIAGED property (does not require a bug id
> perhaps?).
> >>> The people who triage bugs also triage the UNTRIAGED layout tests and
> assign
> >>> them a priority (and file a bug?). The bugs are then fixed via our
> normal
> >>> bug triage process. People own fixing a given layout test by becoming
> the
> >>> owner

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

[David Levin]

I like this proposal.  *I would also like a bugs for P3* which could explain
why it is a P3.  If is it an unimplemented feature, then all tests for that
unimplemented feature could have the same bug.
(Since I do merges and took a while to layout test file bugs from that) I
like option 2.  *BUT I'm concerned that adding someone's email address to
test_fixable will not get any attention.  Right now, when you file a bug,
people get email and the bugs seem to be followed up.*
*
*

BUGS/PRIORITY TRIAGING
Option 1

Addition Pro

Email sent about new bug alerts people to the new issue -- I suppose one
could email people separately when adding their email address to
test_fixable (but this step could easily be missed).


Dave


On Tue, Mar 24, 2009 at 12:14 PM, Marc-Andre Decoste wrote:

> I personally prefer having a bug assigned for the layout tests that we want
> to be fixed soon... 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 sort of dashboard for this, we could add a page 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:
>
>> 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 spreadsheet to take ownership of
>> layout tests and just put our names directly in the test list? This seems
>> way more intuitive to me and avoids needing to look at multiple locations
>> for the state of the layout tests. I like having a read-only dashboard that
>> present this information in a useful way like the spreadsheet currently
>> does, but there should only be one place we modify.
>>
>> BUGS/PRIORITY TRIAGING
>> *Option 1*
>> Every P0/P1/P2 test is required to have a bug id associated with it. New
>> failures get the UNTRIAGED property (does not require a bug id perhaps?).
>> The people who triage bugs also triage the UNTRIAGED layout tests and assign
>> them a priority (and file a bug?). The bugs are then fixed via our normal
>> bug triage process. People own fixing a given layout test by becoming the
>> owner of the bug.
>>
>> Pros:
>> -Works with our current bug triage process (kind of)
>> -Makes for one easy place that people need to look for their todo list
>> (the google code issue tracker)
>> Cons:
>> -Overhead of filing and closing bugs when the common case is just a
>> rebaseline anyways
>> -Hard to triage layout tests without understanding what's wrong with them
>>
>> *Option 2*
>> The same as above, except that bug ids are not required. Bug ids are just
>> for cases where someone has looked into a test and needs to provide
>> information about why/how it's failing, but can't fix it immediately. People
>> become owners for a given layout test by putting their name as one of the
>> metadata bits for that test. Like Option 1, there needs to be a triage
>> process to assign priorities.
>>
>> Pros:
>> -Minimizes overhead of managing layout tests
>> Cons:
>> -Does not work with our current bug process
>> -People need to look in two places to see what issues they need to fix
>> -Hard to triage layout tests without understanding what's wrong with them
>> -Does not send people an email when they get assigned to a test (can be
>> fixed by a simple script though)
>>
>> I lean towards option 2. There is so much churn with layout tests that
>> adding overhead for each failure actually adds a good deal of unnecessary
>> work. In terms of bug triage, I think it needs to happens slightly
>> differently than the current bug triage process anyways since it first
>> requires an engineer (the webkit sheriff?) to find out why each test is
>> failing.
>>
>> *PRIORITIES*
>> P0 - Something is catostrophically wrong and should be fixed now.
>> P1 - Regresssions and tests that have known or likely impact on real
>> sites. Blocks next milestone release.
>> P2 - Tests that we should be passing or for smallish features that we
>> really should have implemented by now (e.g. input type=search)
>> P3 - Tests for large features that we have yet to turn on (e.g. workers)
>>
>> Finaly, it's not clear to me that we need an explicit UNTRIAGED property.
>> If a test lacks a priority, then it's clearly untriaged.
>>
>> Ojan
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: 2-day merges and the cleanup schedule

[David Levin]

I know that I haven't filed chromium bugs for layout test failures in the
past because it isn't in the instructions (I thought adding the the
tests_fixable was sufficient.)

http://dev.chromium.org/developers/how-tos/webkit-merge-1


Though I do usually have at least a partial 3rd day of items for clean up:
upstreaming, some times filing bugs for new reliability crashes, etc.
Dave


On Wed, Mar 4, 2009 at 5:30 PM, Pam Greene  wrote:

> I'm not sure how closely that's followed.  Me, I did merges Monday and
> Tuesday, and layout-test cleanup (baselines and bugs) today.
> - Pam
>
>
> On Wed, Mar 4, 2009 at 5:10 PM, Darin Fisher  wrote:
>
>> Right.  I just mean that the merger should take care to ensure that all of
>> the easy "fixes" are done and that the rest are accounted for somehow,
>> probably via regression bugs.  If that's the current process, then great.
>>  It just sounded like it wasn't.
>> -Darin
>>
>>
>>
>> On Wed, Mar 4, 2009 at 4:51 PM, Pam Greene  wrote:
>>
>>> Define "resolved". Is filing and assigning a bug sufficient? It's not
>>> efficient to have whoever volunteers to do a merge personally pester people
>>> to fix the resulting test errors forever after.
>>> Whatever we do, we're going to have broken layout tests after a merge.
>>> Easy "fixes" -- re-baselining the ones that are actually all right, and
>>> filing specific bugs for the rest -- are definitely part of the merge task.
>>> But we don't want to put too much blame on the messenger: if a bunch of
>>> tests really break, or new tests don't pass, it's hardly the fault of the
>>> person who happened to bring the changes in.
>>>
>>> - Pam
>>>
>>> On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher  wrote:
>>>
 I think the merger should be responsible for ensuring that any layout
 test fallout from the merge gets resolved.  This doesn't mean necessary
 fixing everything, but rather it can be mean reaching out to others for
 help.
 I think the merger has to have incentive not to create a big mess with
 the merge and to also make sure the job gets done completely :-)

 -Darin


 On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet  wrote:

>
> If we are ever to keep up to date with layout tests we need to come to
> a consensus on this. Here's the current set of proposals:
>
> 1. The merge becomes a two day activity. First day is merge, second
> day is fixing any failing layout tests.
> 2. We tag team people: first person does merge, next day another
> person fixes any failing layout tests.
> 3. One person for merge (like we do now), and failures are handled by
> owners of the layout tests. This assumes we can identify owners for
> buckets of layout tests so that folks know they are on the spot for a
> failing test.
>
> At this point we only care about regressions since 1.0, but that'll
> change soon.
>
> Can we make a decision on this at next weeks WebKit meeting?
>
>  -Scott
>
> On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson 
> wrote:
> >
> > I'm currently doing a 2-day merge rotation.As part of this, various
> > layout tests are regressing or getting added that I'm inserting into
> > the tests_fixable list.
> >
> > But, like every other layout test fixer, after my merges are done,
> > I'll finally go back to my old work and not think about it any more.
> > This is how we get a monotonically increasing list of broken tests at
> > the end of the tests fixable. I'm pretty certain this happens faster
> > than the tests are getting fixed because nobody wants to fix them.
> I'm
> > sort of tempted to just fix the ones my merge broke now, but that
> will
> > put me behind for my next merge, so I don't do that.
> >
> > I propose a different rotation schedule for WebKit merges. You would
> > do one day of merges, and the next day you would have to clean up all
> > the regressed and new layout tests your merge introduced. The layout
> > tests usually aren't that hard, so it normally wouldn't take the
> whole
> > day. This way we can be in a good steady state of WebKit merges. It
> > should also have a big advantage for fixing the broken tests since
> the
> > things that changed, the build numbers involved, etc. are still fresh
> > in the merger's head, and it won't be like approaching a random
> layout
> > test from the list with no context.
> >
> > The disadvantage of doing this is that we have to find people to do
> > the merges faster (we should probably formalize the schedule), and
> > you'll lose some advantage the second day of having all the
> > instructions and gotchas of the merge fresh in your mind. I was
> > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but
> > that seems too heavyweight for the people volunteering to do this.
> >
> > Anybody have any com

[chromium-dev] Re: 2-day merges and the cleanup schedule

[David Levin]

Yes, so what would be the process then?  (Will we still have "mergers" whose
job is mostly to handle new and modified layout tests?)
On Wed, Mar 4, 2009 at 4:58 PM, Ojan Vafai  wrote:

> Even once pulling in a new webkit is as simple as changing a revision
> number in DEPS, we'll still have new and modified layout tests that we'll
> need to deal with.
>
>
> On Wed, Mar 4, 2009 at 4:44 PM, David Levin  wrote:
>
>> Aren't we trying to get rid of the merge process (soon-ish)?
>> If so, how would layout tests get fixed at that point?
>>
>> Dave
>>
>> On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher  wrote:
>>
>>> I think the merger should be responsible for ensuring that any layout
>>> test fallout from the merge gets resolved.  This doesn't mean necessary
>>> fixing everything, but rather it can be mean reaching out to others for
>>> help.
>>> I think the merger has to have incentive not to create a big mess with
>>> the merge and to also make sure the job gets done completely :-)
>>>
>>> -Darin
>>>
>>>
>>> On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet  wrote:
>>>
>>>>
>>>> If we are ever to keep up to date with layout tests we need to come to
>>>> a consensus on this. Here's the current set of proposals:
>>>>
>>>> 1. The merge becomes a two day activity. First day is merge, second
>>>> day is fixing any failing layout tests.
>>>> 2. We tag team people: first person does merge, next day another
>>>> person fixes any failing layout tests.
>>>> 3. One person for merge (like we do now), and failures are handled by
>>>> owners of the layout tests. This assumes we can identify owners for
>>>> buckets of layout tests so that folks know they are on the spot for a
>>>> failing test.
>>>>
>>>> At this point we only care about regressions since 1.0, but that'll
>>>> change soon.
>>>>
>>>> Can we make a decision on this at next weeks WebKit meeting?
>>>>
>>>>  -Scott
>>>>
>>>> On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson 
>>>> wrote:
>>>> >
>>>> > I'm currently doing a 2-day merge rotation.As part of this, various
>>>> > layout tests are regressing or getting added that I'm inserting into
>>>> > the tests_fixable list.
>>>> >
>>>> > But, like every other layout test fixer, after my merges are done,
>>>> > I'll finally go back to my old work and not think about it any more.
>>>> > This is how we get a monotonically increasing list of broken tests at
>>>> > the end of the tests fixable. I'm pretty certain this happens faster
>>>> > than the tests are getting fixed because nobody wants to fix them. I'm
>>>> > sort of tempted to just fix the ones my merge broke now, but that will
>>>> > put me behind for my next merge, so I don't do that.
>>>> >
>>>> > I propose a different rotation schedule for WebKit merges. You would
>>>> > do one day of merges, and the next day you would have to clean up all
>>>> > the regressed and new layout tests your merge introduced. The layout
>>>> > tests usually aren't that hard, so it normally wouldn't take the whole
>>>> > day. This way we can be in a good steady state of WebKit merges. It
>>>> > should also have a big advantage for fixing the broken tests since the
>>>> > things that changed, the build numbers involved, etc. are still fresh
>>>> > in the merger's head, and it won't be like approaching a random layout
>>>> > test from the list with no context.
>>>> >
>>>> > The disadvantage of doing this is that we have to find people to do
>>>> > the merges faster (we should probably formalize the schedule), and
>>>> > you'll lose some advantage the second day of having all the
>>>> > instructions and gotchas of the merge fresh in your mind. I was
>>>> > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but
>>>> > that seems too heavyweight for the people volunteering to do this.
>>>> >
>>>> > Anybody have any comments?
>>>> > Brett
>>>> >
>>>> > >
>>>> >
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: 2-day merges and the cleanup schedule

[David Levin]

Aren't we trying to get rid of the merge process (soon-ish)?
If so, how would layout tests get fixed at that point?

Dave

On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher  wrote:

> I think the merger should be responsible for ensuring that any layout test
> fallout from the merge gets resolved.  This doesn't mean necessary fixing
> everything, but rather it can be mean reaching out to others for help.
> I think the merger has to have incentive not to create a big mess with the
> merge and to also make sure the job gets done completely :-)
>
> -Darin
>
>
> On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet  wrote:
>
>>
>> If we are ever to keep up to date with layout tests we need to come to
>> a consensus on this. Here's the current set of proposals:
>>
>> 1. The merge becomes a two day activity. First day is merge, second
>> day is fixing any failing layout tests.
>> 2. We tag team people: first person does merge, next day another
>> person fixes any failing layout tests.
>> 3. One person for merge (like we do now), and failures are handled by
>> owners of the layout tests. This assumes we can identify owners for
>> buckets of layout tests so that folks know they are on the spot for a
>> failing test.
>>
>> At this point we only care about regressions since 1.0, but that'll change
>> soon.
>>
>> Can we make a decision on this at next weeks WebKit meeting?
>>
>>  -Scott
>>
>> On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson 
>> wrote:
>> >
>> > I'm currently doing a 2-day merge rotation.As part of this, various
>> > layout tests are regressing or getting added that I'm inserting into
>> > the tests_fixable list.
>> >
>> > But, like every other layout test fixer, after my merges are done,
>> > I'll finally go back to my old work and not think about it any more.
>> > This is how we get a monotonically increasing list of broken tests at
>> > the end of the tests fixable. I'm pretty certain this happens faster
>> > than the tests are getting fixed because nobody wants to fix them. I'm
>> > sort of tempted to just fix the ones my merge broke now, but that will
>> > put me behind for my next merge, so I don't do that.
>> >
>> > I propose a different rotation schedule for WebKit merges. You would
>> > do one day of merges, and the next day you would have to clean up all
>> > the regressed and new layout tests your merge introduced. The layout
>> > tests usually aren't that hard, so it normally wouldn't take the whole
>> > day. This way we can be in a good steady state of WebKit merges. It
>> > should also have a big advantage for fixing the broken tests since the
>> > things that changed, the build numbers involved, etc. are still fresh
>> > in the merger's head, and it won't be like approaching a random layout
>> > test from the list with no context.
>> >
>> > The disadvantage of doing this is that we have to find people to do
>> > the merges faster (we should probably formalize the schedule), and
>> > you'll lose some advantage the second day of having all the
>> > instructions and gotchas of the merge fresh in your mind. I was
>> > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but
>> > that seems too heavyweight for the people volunteering to do this.
>> >
>> > Anybody have any comments?
>> > Brett
>> >
>> > >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: 2-day merges and the cleanup schedule

[David Levin]

I don't think this is a good idea.  With respect to two days of merging, it
was a good thing (for me).  For one thing, the first day was an absolute
pain and it took me well into the second day to get it checked in.  On the
other hand, the second merge was a breeze by comparison (no added/remove
files, no method name changes needed in own code, etc.)
It took me a least three days.  After merging various unit test failures got
blaimed on the merge so I tracked down those failures and submitted fixes
(and they weren't the fault of the merge but instead due to a unit test
re-sorting that happened to occur at the same time.)

In addition, after the merge, you need to upstream the changes that you had
to do back to webkit.  Not too hard but it adds time.

With respect to layout test, we could do two things:
1. Have a layout test fixers that rotate like merges.  That seems like what
Brett is proposing anyway but tacking it on to the people doing the merges.
2. Have folks who are familiar with the areas look at the breaks.
If the fix is easy, then it should be fast to rebaseline, etc.  (If it isn't
easy, then the people doing merges, aren't going to do it any faster.)

If you had stuck me on fixing layout tests after the merge, I would have
spent a day on it and likely accomplished not much (nothing) due to my lack
of familiarity with Chromium code (sorry, I mostly work on WebKit).

Dave

PS If anyone not doing merges feels like the people doing merges should do
more, please volunteer to do a merge so at least you'll know what it is like
 -- Sorry Scott but I'm looking at you :)


On Thu, Jan 15, 2009 at 2:26 PM, Pam Greene  wrote:

> On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson  wrote:
>
>>
>> On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene  wrote:
>> > When fixing layout tests only means re-baselining, that's easy. But
>> > sometimes they break (or new ones fail) for deeper reasons, and the
>> person
>> > doing the merge may not be the right one to make the fix (or may not be
>> able
>> > to fix them in one day).  So perhaps "clean up" in this context means
>> > "re-baseline if that's all it needs, and file individual bugs on
>> specific
>> > people for bigger brokenness".
>>
>> I think our tendency to file bugs and forget about it is part of the
>> problem. I am at least as guilty as anybody else. I think the merger
>> should have the responsibility to get their regressions fixed. They
>> will have to talk with some other people to get input. If they aren't
>> the right person to fix a problem, it should be their responsibility
>> as part of the cleanup to make sure that the right person has been
>> assigned to it and is actually working on it.
>
>
> Taking responsibility, check. Making sure someone is assigned, check.
> Fixing tricky regressions yourself may not be the most efficient use of
> time, and would be a strong deterrent to volunteer for a merge.  Merging
> isn't much fun; fixing layout tests isn't much fun.  Let's spread the pain
> where suitable, rather than piling it all on the person who volunteers for
> one part.
>
> In fact, I'd ask the merger to fix the "easy" problems (tests changed, new
> tests need baselines) before committing the merge.
>
>
>> When people are assigned merge bugs, they should be treated as
>> important regressions and prioritized over other work. We currently
>> had a whole lot of layout tests bugs filed that are getting no love.
>> The only way to not keep getting behind is to be much more proactive.
>
>
> Absolutely.
>
>
>> > Also, to clarify, are you proposing that we only merge every other day,
>> or
>> > that we have two people assigned each day: one to merge and one to clean
>> up
>> > the previous day's layout-test breakage?  If the latter, we could also
>> split
>> > the job in the other direction, and have one person merging two days in
>> a
>> > row and one fixing up the test list both days.  I could imagine people's
>> > tastes running more to one job or the other, and we don't really care
>> who
>> > does what as long as it gets done.
>>
>> I'm proposing overlapping so we merge every day. I think there is an
>> advantage in having the same person who did the merge do the fixing.
>> This hopefully also makes the merge less tedious since you have
>> different tasks your two days.
>
>
> Sounds fine. People can always trade if they want.
>
> - Pam
>
>
>> Brett
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: What WebKit goodies do we get in 155?

[David Levin]

This fellow has done a good job of highlighting improvements to WebKit on an
on going basis:
  http://hanblog.info/blog/category/WebKit
Of course, not everything mentioned in there is in available just because
we're at ToT.  (Some things are behind ifdef's etc.)


On Mon, Jan 5, 2009 at 11:06 PM, Adam Barth  wrote:

>
> If 155 is coming off of trunk, it has postMessage(), which is exciting
> for us security wonks.
>
> Adam
>
>
> On Mon, Jan 5, 2009 at 9:30 PM, Mark Larson (Google) 
> wrote:
> > I'm working on release notes for 155. The big addition in 155 (vs the 154
> > code we've been releasing) is the WebKit update.
> > What have we gained since we started merging to WebKit's trunk?
> > So far, I've got
> >   -- full page zoom
> >   -- autoscroll
> >   -- CSS gradients
> >   -- CSS canvas drawing
> >   -- (partly) CSS masks
> >   -- (partly?) CSS reflections
> > Can you think of other features worth noting in release notes?
> > Thanks,
> > Mark
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Please announce via email when clobbers are required

[David Levin]

So how does one know if the change they checked in requires a clobber build?
Dave

PS I tend to do clean builds once in a while just to ensure that everything
is in a good state.  (I don't trust incremental builds to stay stable over
several days having spent way too much time on messed builds due to
non-clean state in other projects in my past.)

On Tue, Dec 9, 2008 at 9:37 AM, Mike Pinkerton <[EMAIL PROTECTED]>wrote:

>
> > Given that clobbers are sometimes a necessary and required part of our
> > build process, we as a team need to do a better job communicating when
> > they're required. IRC and the waterfall are one step, but for those
> > that don't build on all platforms every day, a passing status message
> > may go un-noticed. As a result, I'm asking folks to please send out an
> > email to this list when a clobber is required.
>
> By the way, I forgot to mention that a change requiring a clobber was
> checked in yesterday (monday), so folks building on Windows will need
> to clobber in order to build.
>
> This has been a public service announcement :-)
>
> --
> Mike Pinkerton
> Mac Weenie
> [EMAIL PROTECTED]
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---