[chromium-dev] [LTTF] Q1 Plan
Greetings, people of Chromium! Last quarter, the Layout Test Task Force done some pretty good work. I bragged about it in a separate email. Now it's time to grab the bull by the horns and kick it up a notch. Isn't idiomatic English great? This quarter, the LTTF is aiming right at the heart of the problem: eliminating the need to continually roll WebKit DEPS, baking in layers upon layers of regressions in the phyllo dough that is our test_expectations file. To do that, we must move all of our layout test infrastructure, from test_shell to test expectations to flakiness dashboard upstream. Based on a few hallway/online/cross-continental conversations, our plan of action consists of three efforts (drivers in parentheses): - Port test_shell into DumpRenderTree (DRT) upstream (Tokyo LTTF team + dglazkov + darin) - Take care of chromium dependencies: base, net, skia (src/skia, that is). How will they manifest themselves upstream to avoid breakage due to changes in chromium tree? (dglazkov, darin, tc) - Identify strategy for DRT and V8 coexistence: currently all of DRT is heavily JSC-dependent. We should either introduce script-independent abstractions or convert to NPAPI that we use downstream (dglazkov, darin, tc). - Figure out for inflight testing. How will we ensure that porting doesn't introduce new bugs? Need to come up with a way to have a workable DRT quickly, and a way to produce differential of layout test failures to quickly find porting bugs. - Upstream src/webkit/tools/test_shell to WebKitTools/DumpRenderTree/chromium. - Coordinate with harness upstreaming effort, so that both run-webkit-tests and the new DRT work well together while porting. - Determine how we will remove code downstream. We won't need DRT-specific code, but may still need test_shell as a minimum-capabilities embedder of WebKit. Or we could go with a MiniBrowser-style project (open-source sample for WebKit Apple port) upstream. - Drive effort to completion. *Completion is*: DRT is ready to run layout tests on build.webkit.org, downstream cleaned up and ready to stop running layout tests on build.chromium.org. - Upstream test infrastructure (watch detailed plan and assignments develop at http://dev.chromium.org/developers/design-documents/upstreaminglayouttests). Steps include: - Move run_webkit_tests.py to live upstream - While DRT is being upstreamed, configure to run upstreamed run_webkit_tests on the Chromium builders - Move test expectations upstream - Move ancilliary tools, like rebaseline.py and flakiness dashboard upstream - Modify run_webkit_tests to use the newly upstreamed DRT - Drive effort to completion. *Completion is*: build.webkit.org is running layout tests with no regressions from downstream, build.chromium.org no longer runs layout tests. - Continue fixing/deflakifying layout tests and improving the process for sustaining compatibility. - Fix chrome-specific failures that dramatically affect compatibility (bug triage -- which means *you*!) - Fix SVG/Skia bugs that cause layout test failures (Waterloo team) - Fix V8 bugs and develop ES5 features that affect layout tests (V8 team) - Make V8 bindings more tolerant to IDL/JSC changes. Watch the effort as a bug tree: https://bugs.webkit.org/showdependencytree.cgi?id=32630hide_resolved=0 (japhet, kkanetkar) - Improve gardening tools and process (dglazkov) - Eliminate layout test flakiness (jparent, ojan, dglazkov) - Drive effort to completion. *Completion is*: 10 sustained layout test failures or flakes, bindings-related regressions/breaks are limited to custom code only, new process for keeping up for layout test regressions is adopted by Webkit Gardeners. As you can see, it's a bit different from grab a test and fix it approach we took in Q4. We learn, right? :) Despite most tasks having a driver in one form or another, we always welcome your contributions. Every little bit counts. :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] [LTTF] Finders Pool Drained, Under 300 Failures on Win XP Release
Dear Chromium Folk, Today, something vaguely significant happened -- if you're into numbers, statistic, and fixing layout tests. And you have to admit, all of us are. First, after a week of relentless triage, I finally drained the Finders pool. The Finders pool? you ask, flashing back to your last treasure hunt adventure. No, not that kind of finders pool -- well.. almost. See, over the time of project existence, we accumulated quite a few layout test failures. As the Layout Test Task Force was chartered, we split all of our failures into two pools: 1) the failures whose causes are known and are ready for fixing, or the Fixers Pool 2) the failures that fail for reasons that are yet to be found, or the Finders Pool We even have this really neat dashboard (http://chromiumlttf.appspot.com/ -- thanks for building it, dpranke!) that shows us these known knowns and known unknowns (http://www.brainyquote.com/quotes/quotes/d/donaldrums148142.html). Over the last few months, we've been diminishing the size of the Win XP Release Finders pool, and last week I decided that the time has come for it to say buh-bye. And id did! Now we _only_ have 159 bugs to fix and we'll have 0 layout test failures. But at least we know what to fix, right? I mean -- right? ;) Oh -- and we have to keep this pool empty. Any creepage of unknown failures will not be tolerated. Except when it's a flake -- we'll soon have a separate triaging bucket for those, but for now all flaky tests go into the Fixers pool. My sincere apologies to tkent, jar, nsylvain, jungshik, sdoyon, ericu, cevans, senorblanco and yuzo for inflicting the barrage of rebaselining and expectation tweaking commits during their sheriffing duty. That tree closing yesterday due to too many commits was partially my fault. Second, as a result of the aforementioned drainage, the Win XP Release bot is finally showing under 300 failures! Woo hoo! This means that over the last 4 months (or the entire length of its existence), the LTTF eliminated over 500 test failures from the tree. That's big stuff, folks. Kudos to you all, LTTF-ers. I salute you on behalf of the entire Chrome team and WebKit community, since a lot of tests fixed were not specific to Chrome. Anyhow, have a good night, y'all. Except for the WebKit gardeners -- who as it's widely known never sleep. :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] WebKit Gardeners 3 rebaseline.py -w
Before heading out for the weekend, I just want to mention this: rebaseline tool really, really rocks. And yesterday I discovered an option that I, to my shame, hadn't seen before: -w. This option pulls baselines from the canary. It's like getting test expectations from the future! In other words, there are no more excuses for you, dear WebKit gardeners, to commit those ghastly BUG_SOMENAME entries in test_expectations. The workflow is mind-numbingly simple: 1) Identify tests that need rebaselining prior to rolling 2) Add these tests to test_expectations.txt as if you were to commit them -- except add a REBASELINE flag next to BUG_SOMENAME 3) Run rebaseline -w 4) Make sure that the tool ran and removed these entries from test_expectations.txt 5) Create CL -- you will notice how new expected result files are conveniently added for you. 6) Enjoy regression-free WebKit roll. Big thanks to Victor Wang for this amazing instrument of everlasting harmony. Send him your accolades. Or cash. If you find bugs/quirks, fix them. :DG P.S. As part of gardener/sheriff process overhaul, I will be adding these and other helpful tips/hints to our gardening doc. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] r34565 clobber notice: IncrediBuild + Recent WebKit Roll = :(
I just committed a WebKit roll (r34565) which requires clobbering if you're running IncrediBuild. Not sure why, but that's the outcome I've seen on on the build bots. If you compile using native VS compiler, the dependency-tracking works correctly. Mac and Linux builds are not affected. If you don't clobber, you won't get compile errors. Instead, you'll see fun layout test and test_shell tests failures, like so: http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20(webkit.org)/builds/17668 :DG -- 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] WebKit roll status
I wonder if we should investigate and determine the cause of Linux failures before rolling. :DG On Tue, Dec 8, 2009 at 12:43 PM, Stephen White senorbla...@chromium.org wrote: For the curious, as of WebKit 51800, SVG Filters are enabled by default. In theory (since this code is cross-platform), this should just require us turning them on in Chrome, and rebaselining the affected tests (about 24 on Windows). In practice, however, some of the code behind #if ENABLE(SVG_FILTERS) on the V8 bindings side may have rotted, and need some attention. Also, there are also a huge number of additional tests are failing on Linux (481) for reasons unknown as yet. This issue is being tracked at http://code.google.com/p/chromium/issues/detail?id=29737 Stephen On Tue, Dec 8, 2009 at 3:23 PM, Michael Nordman micha...@chromium.org wrote: Hi all, Just a note to let you know what's up with webkit rolls (or lack thereof) right now. We're at r51794 and have been for a while. Tip-of-tree webkit is at r51868. * All manner of svg tests are borked from some reason around r 51800, senorblanco is on that. * A couple of build breaks obscured things for a while, ajwong has resolved those already. I'm putting together a CL to roll deps to r51868 and update test expectations to expect the svg failures (as recommended by senorblanco). This may be a little bit of a bumpy ride. PS. Oh, and my car broke down this morning. Just my lucky day i guess :) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer -- 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] WebKit roll status
- fix the problem with the black scrollbars in testshell. This is easy. The WebKit change currently sets all colors to zero, unless somebody explicitly sets them to something else. We can pick different default values that will at least make the scrollbars visible. This would still require rebasing the pixel tests. And we have to make a decision on whether to apply this as an incremental change or whether to rollback the current WebKit change. It's gonna be a rely simple low-risk change. Let's go with this. You'll have a chance all about the great rebaselining tool in the process. :) Michael will roll and add all the failures to expectations, creating a bug for you to rebaseline. :DG Markus On Tue, Dec 8, 2009 at 13:09, Dimitri Glazkov dglaz...@chromium.org wrote: Ouch. And all scrollbars in pixel tests are now black (see attached). Yeah, I think we should roll this one out. Welcome to the wonderful world of WebKit, Markus! :DG On Tue, Dec 8, 2009 at 12:59 PM, Adam Langley a...@google.com wrote: On Tue, Dec 8, 2009 at 12:55 PM, Michael Nordman micha...@chromium.org wrote: yikes 481 failures on linux... k... holding off rolling until we get a handle on the nature of the linux borkage This is probably the result of Markus's first WebKit patch. It was LGTMed and he asked that it be landed and didn't think that it would break anything. However, it appears that he didn't know about the pixel tests! http://trac.webkit.org/changeset/51827 You might want to revert it for now, although it should be ok to rebaseline any pixel tests that changed. It's just a very minor change in the scrollbar colours. AGL -- 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: Something smells weird on the buildbot
On Thu, Dec 3, 2009 at 10:07 AM, Ojan Vafai o...@google.com wrote: +chromium-dev as others who look at the waterfall might also be confused. On Thu, Dec 3, 2009 at 8:50 AM, Dimitri Glazkov dglaz...@google.com wrote: Sending out random people, because it's early :) There's a couple of things I see on the bot this morning: 1) There's a crashing test on all bots -- and the tree is still green! http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html#tests=LayoutTests/plugins/embed-attributes-setting.html The test is consistently crashing when run with all the other tests, but passing when we retry it in isolation. Note that the test is listed as an unexpected flaky test on the waterfall. This is one of the downsides of retrying failing tests. We can't distinguish flakiness from this case. We just need to careful to not ignore unexpected flakiness on the waterfall. Note that the dashboard only shows the result from the first run. Including the retry results from the bots seems like more trouble than it's worth. Should unexpected flakiness turn the bot red? :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: Something smells weird on the buildbot
On Thu, Dec 3, 2009 at 10:17 AM, Nicolas Sylvain nsylv...@chromium.org wrote: Should unexpected flakiness turn the bot red? If it turns the bot red, then it defeats the purpose of that code. Might as well not retry and mark it as FAIL. (which turns the tree red). Duh :) Makes sense. How about we turn red for unexpected crashiness? :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: Layout tests can now be run on Win 7
Great stuff! Thanks for working on this. No longer do I have to add --nocheck-sys-deps to all of my commands. fetch me a cofee no fetch me a coffee --nocheck-sys-deps ok. :DG On Tue, Nov 3, 2009 at 6:31 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I have just checked in a new set of baselines that should allow you to run the layout tests on Win 7 as well as Vista and XP. For those of you playing along at home, this means that if you have a baseline that is windows 7 specific, or is the same across 7, Vista, and XP, check it into src/webkit/data/platform/chromium-win. If you have a baseline that is specific to Vista or is the same on Vista and XP, check it into src/webkit/data/platform/chromium-win-vista, and if you have an XP-specific baseline, check it into src/webkit/data/platform/chromium-win-xp. 99.9% of all of your baselines will be generic, so you can probably just check it into chromium-win and let me fix diffs when they crop up down the road. Also, if you have a test that only fails on Win 7, you can specify WIN-7 in test_expectations.txt. But, I wouldn't expect any of those. Cheers, and any questions or problems on this should go to me, -- 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] Fie Foh Fum! I smell the blood of the WebKit-man: MStone:4 is nigh.
The moon is high. The zombies, wizards and various other bizarre beings are prowling the streets. Which could mean only one thing: Tombstone 4 is coming to get us. http://crbug.com/horizon/webkit So be prepared, dear WebKit Chromium people. On Monday, check your bug list: http://crbug.com/?q=owner:me+Mstone:4 Make an effort. Fix yer bugs. Help us escape what could be a terrifying conclusion of this stable release. :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: Crashing layout tests
Yaar and I discussed making changes to that effect last week, he's working on that. :DG On Tue, Oct 20, 2009 at 10:33 AM, David Levin le...@chromium.org wrote: 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 jor...@chromium.org wrote: On Tue, Oct 20, 2009 at 10:19 AM, David Levin le...@google.com 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 jor...@chromium.org 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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Oct 13, 2009 at 9:26 AM, Darin Fisher da...@chromium.org wrote: On Tue, Oct 13, 2009 at 8:21 AM, Adam Barth aba...@chromium.org wrote: On Tue, Oct 13, 2009 at 8:09 AM, David Levin le...@google.com wrote: 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. I agree this is essential. 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). Eric is going to add commit-queue coverage for the V8 bindings, which should help with this problem significantly. I think this is a great addition, but shouldn't the canary bots have had just as much of a chance of catching this issue? Why didn't they catch it? Is it b/c of flakiness? If so, then try bots won't help that much. What I think we need to do is beef up the canary bots so that they provide equivalent coverage to the mainline Chromium bots. This will be essential if we ever wish to roll WebKit less often (once per week say), which will only really be possible once we have the WebKit API. -Darin The canaries did catch it. The gardener is also to blame for this. :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] [LTTF][WebKit Gardening]: Keeping up with the weeds.
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 layout tests, which brings the suffering and spells asymptotic doom to the LTTF effort. POSSIBLE SOLUTIONS: * Extend WebKit gardener's duties to 4 days. First two days you roll. Next two days you fix layout tests. Not file bugs -- actually fix them. The net result of 4 days should be 0 (or less!) new layout test failures. This solution kind of expects the gardener to be part of LTTF, which is not always the case. So it may not seem totally fair. * Assign LTTF folks specifically for test clean-up every day. The idea here is to slant LTTF effort aggressively toward fixing newer failures. This seems nice for the gardeners, but appears to separate the action/responsibility dependency: no matter what you roll, the LTTF elves will fix it. * [ your idea goes here ] TIMELINE: I would like for us to agree on a solution and make the necessary changes to the process today. Tomorrow is a new day, full of surprising changes upstream. :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: [LTTF][WebKit Gardening]: Keeping up with the weeds.
Let's not conflate the two. There are flakes, and there are clearly, consistently failing tests, arriving in chunks every day via WebKit rolls. :DG On Tue, Oct 13, 2009 at 10:36 AM, Peter Kasting pkast...@google.com wrote: When I'm sheriffing, the vast majority of issues I see are flaky tests in general rather than clear bustage from WebKit updates. Even if a particular update causes flakiness, it can be hard to determine and fix. In that sense, the highest priority IMO would be to eliminate flakiness, which would make failures clearer and easier to track down no matter who was responsible. 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: [LTTF][WebKit Gardening]: Keeping up with the weeds.
Based on the feedback, it sounds like we need to take the approach with LTTF team adding more resources on cleaning up the bottom of the test_expectations file (i.e. stuff recently added by the gardeners). It is still the gardener's responsibility to take care of the rebaselines, right? What should they do with the rest? File bugs? Mark as BUG_LTTF? :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: [LTTF][WebKit Gardening]: Keeping up with the weeds.
specific bug. -atw On Tue, Oct 13, 2009 at 10:40 AM, Pam Greene p...@chromium.org 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 dglaz...@chromium.org 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 layout tests, which brings the suffering and spells asymptotic doom to the LTTF effort. POSSIBLE SOLUTIONS: * Extend WebKit gardener's duties to 4 days. First two days you roll. Next two days you fix layout tests. Not file bugs -- actually fix them. The net result of 4 days should be 0 (or less!) new layout test failures. This solution kind of expects the gardener to be part of LTTF, which is not always the case. So it may not seem totally fair. * Assign LTTF folks specifically for test clean-up every day. The idea here is to slant LTTF effort aggressively toward fixing newer failures. This seems nice for the gardeners, but appears to separate the action/responsibility dependency: no matter what you roll, the LTTF elves will fix it. * [ your idea goes here ] TIMELINE: I would like for us to agree on a solution and make the necessary changes to the process today. Tomorrow is a new day, full of surprising changes upstream. :DG -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ 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 Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov dglaz...@google.com wrote: Today wasn't a happy day for p...@. He did a seemingly innocuous roll that broke the world: selenium, ui tests, layout tests. I am sure it was stressful and probably added unnecessary gray to his hair. 2) writers of patches don't test them properly. In Paul's case, it was http://trac.webkit.org/changeset/48639, again by a teammate, and it looks like the patch wasn't very thoroughly tested -- it showed a few regressions in the canary, but because it had to do with V8 garbage collection, the failures were intermittent and seemingly random. However, landing it on trunk looked like a shrapnel blast. Happened again today. Alpha (hclam@) was the most recent victim, along with the prolonged tree closure and sheriff-firefighting. Here's the perp: http://trac.webkit.org/changeset/49429. May I suggest a heaping of WebKit gardening duty as the preventive therapy? :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: detecting tabs using a lot of CPU?
+1 to glowing hot idea! :DG On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
Good point on HTML. Why not instead make DevTools better/faster/do-what-you-want-them-to-do? :DG On Tue, Sep 29, 2009 at 9:08 AM, Evan Martin e...@chromium.org wrote: I'd like to suggest early on that it's done in HTML for the usual reasons. (And also that there are the usual negatives. Just wanna plant the seed.) In particular, a meta-page page would allow the typical operations on subresource links (click to view; media playing would work in-browser; right-click to download) and our HTML-based extensions would integrate better (no need to be stuck in an extra tab on the side with jarringly different UI compared to native controls). On Mon, Sep 28, 2009 at 8:00 PM, Robert Sesek rse...@chromium.org wrote: For reference: http://code.google.com/p/chromium/issues/detail?id=5973 I'd be interested in helping out with this on the Mac side. I filed a Camino bug a couple of years ago about something similar. Safari has a helpful tool in Window -- Activity that allows you to download all resources of a page (including XHR and others loaded through JS). DevTools does something similar, but compared to Safari's interface it's slower and harder to find things (the entries in the list take up more vertical space). rsesek / @chromium.org On Fri, Sep 25, 2009 at 10:25 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ 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: using upstream webkit's git repo in chrome
You've hit the laziness landmine :) The instructions on http://code.google.com/p/chromium/wiki/UsingWebKitGit go like this: 1) see how to change your .gclient on http://dev.chromium.org/developers/contributing-to-webkit (that is, add the big custom_deps hunk) 2) then change first line to Webkit: None. :DG On Tue, Sep 29, 2009 at 12:06 PM, Drew Wilson atwil...@chromium.org wrote: I'm trying to follow these suggestions, but I'm getting a ton of errors when trying to do a gclient sync when third_party/WebKit is a clone of git.webkit.org. For example: svn: '/Users/atwilson/chrome.git/src/third_party/WebKit/WebKitLibraries' is not a working copy Error: Can't update/checkout '/Users/atwilson/chrome.git/src/third_party/WebKit/WebKitLibraries' if an unversioned directory is present. Delete the directory and try again. I can go through and individually add these directories to my .gclient file, but after I added the 8th one it occurs to me that I'm probably Doing It Wrong. Do you guys have a bunch of exclusions in your .gclient, or is there another way? -atw On Tue, Sep 8, 2009 at 12:07 PM, Evan Martin e...@chromium.org wrote: I checked in tools/sync-webkit-git.py as a stopgap. Description pasted below; let me know if it works/doesn't work for you. === Under the assumption third_party/WebKit is a clone of git.webkit.org, we can use git commands to make it match the version requested by DEPS. To use this: 1) rm -rf third_party/WebKit 2) git clone git://git.webkit.org/WebKit.git third_party/WebKit 3) run ./tools/sync-webkit-git.py now, and again whenever you run gclient sync. FAQ: Q. Why not add this functionality to gclient itself? A. DEPS actually specifies to only pull some subdirectories of third_party/WebKit. So even if gclient supported git, we'd still need to special-case this. --~--~-~--~~~---~--~~ 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: Try-ing WebKit patches (was WebKit Chromium Port Update Sep 29th)
Honestly -- haven't been actually doing anything in the past 3 weeks. Still an AI to write up a proposal :) :DG On Tue, Sep 29, 2009 at 1:08 PM, Marc-Antoine Ruel mar...@chromium.org wrote: +Dimitri, who is doing that and didn't put Jeremy in the loop. On Tue, Sep 29, 2009 at 4:06 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Sep 29, 2009 at 12:52 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Sep 29, 2009 at 12:05 PM, Eric Seidel esei...@chromium.org wrote: On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman y...@chromium.org wrote: 1. An internal webkit chromium port try bot: Will help test webkit-only patches. At first stage, it will test build failures (saving many of us the need to manually test on 3 platforms), but later will also conduct chromium port layout tests and api unit tests. By internal do you mean that only Googlers can access it? Is there a command I could wire into bugzilla-toll post-diff which would post to this try-bot as well? Could you detail such a command? I believe that only people with @chromium.org accounts can currently use try bots. I'm not aware of any discussion about whether or how we should give access to @webkit.org people. Btw, I think it's fairly clear we should give access to WebKit developers; I just haven't seen/heard any discussions about it. And there might be security concerns that make it impossible to simply allow every WebKit contributor to use them without some additional sign up process. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [LTTF]: LayoutTest bugs marked as WontFix and what to do with them.
Dear Finder-folks, As you sift through lines in test_expectations.txt, you may discover that some of them have bugs that are marked as duplicate or even WontFix. Please don't let the crbug.com bug status fool you -- if they are in test_expectations, they are still bugs. In such cases, please: 1) change test_expectations bug number to the valid one if you find the referenced bug is marked as duplicate. 2) file a new bug with the cause -- just as you normally would -- and update test_expectations with it. :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: [LTTF]: LayoutTest bugs marked as WontFix and what to do with them.
To clarify: if a bug is marked as WONTFIX in test_expectations, it is indeed a WontFix. To summarize: always trust what's in test_expectations.txt. :DG On Mon, Sep 28, 2009 at 11:00 AM, Dimitri Glazkov dglaz...@google.com wrote: Dear Finder-folks, As you sift through lines in test_expectations.txt, you may discover that some of them have bugs that are marked as duplicate or even WontFix. Please don't let the crbug.com bug status fool you -- if they are in test_expectations, they are still bugs. In such cases, please: 1) change test_expectations bug number to the valid one if you find the referenced bug is marked as duplicate. 2) file a new bug with the cause -- just as you normally would -- and update test_expectations with it. :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 Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
1) writers of patches don't mention that the patch is two-sided and will break Chromium if landed prematurely. I don't have to go far for an example. Commit queue bot landed http://trac.webkit.org/changeset/48659 a few minutes ago and broke the canary. This means that the canary will be red all night and any subsequent regressions will either not be noticed or create more complications. As I found out later that night (as I was fixing the bustage), this particular break wasn't due to the two-sided nature of the patch. It was a couple of missing includes. Apologies for mis-placing it into this category. This one was from the #2 pile :) :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 Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
I think this is a great idea! Do we have a Python/gcl/rietveld expert who can tackle this? :DG On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek j...@chromium.org wrote: I didn't know this was possible. It seems it will get a lot more usage if it just works, i.e. the try script grabs these settings automatically from a codereview.settings file. If we start by putting this file in third_party\WebKit, then people who start with their patch there (also to upload) can use this transparently. What do you think? On Wed, Sep 23, 2009 at 7:42 AM, Marc-Antoine Ruel mar...@chromium.org wrote: On Tue, Sep 22, 2009 at 9:35 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party I know the format is not very user friendly but it is definitely possible. You probably can skip --use_svn and --svn_repo or at least use the --http stuff instead, see go/chrometryserver. You could want to use both the layout tests and the normal tests so you can send the patch to all the slaves at the same time, e.g. --bot win,linux,mac,layout_win,layout_mac,layout_linux If the layout tests try slaves get overused, I'll add more slaves. 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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
BTW, I trying to be snarky in my request. More like begging :) :DG On Wed, Sep 23, 2009 at 10:08 AM, John Abd-El-Malek j...@chromium.org wrote: Marc-Antonie knows the try scripts best, so to avoid volunteering him directly, I'll say that I'm sure he can answer any questions from whoever does this. I don't think it'll be much work. On Wed, Sep 23, 2009 at 10:04 AM, Dimitri Glazkov dglaz...@google.com wrote: I think this is a great idea! Do we have a Python/gcl/rietveld expert who can tackle this? :DG On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek j...@chromium.org wrote: I didn't know this was possible. It seems it will get a lot more usage if it just works, i.e. the try script grabs these settings automatically from a codereview.settings file. If we start by putting this file in third_party\WebKit, then people who start with their patch there (also to upload) can use this transparently. What do you think? On Wed, Sep 23, 2009 at 7:42 AM, Marc-Antoine Ruel mar...@chromium.org wrote: On Tue, Sep 22, 2009 at 9:35 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party I know the format is not very user friendly but it is definitely possible. You probably can skip --use_svn and --svn_repo or at least use the --http stuff instead, see go/chrometryserver. You could want to use both the layout tests and the normal tests so you can send the patch to all the slaves at the same time, e.g. --bot win,linux,mac,layout_win,layout_mac,layout_linux If the layout tests try slaves get overused, I'll add more slaves. 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: Getting pixel tests running on the Mac
On Wed, Sep 23, 2009 at 12:33 PM, Ojan Vafai o...@chromium.org wrote: +pam, tc, darin in case they disagree with what I'm saying here. Also a bunch of current expectations would need to be modified. All the cases where there is currently FAIL would need to be changed to either FAIL or IMAGE or both if it's a text and image failure. You should be able to get most of the data for this by looking at the layout test dashboard. The only exception is you won't be able to distinguish tests that fail both image and text from tests that only fail image. A short-term solution could be to leave FAIL meaning IMAGE and/or TEXT and adding IMAGE and TEXT for image-only and text-only failures. Then we can gradually excise the FAIL lines from text_expectations. I think is a great plan. :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: git-try chromium + webkit
Thank you so much for doing this! :DG On Tue, Sep 22, 2009 at 9:39 AM, Yaar Schnitman y...@chromium.org wrote: If you use (or consider using) Git, and also work on webkit (or any other 3rd party dependency actually) you may find the following valuable: The latest depot_tools (revision 26817+) makes it possible to use git-try to simultaneously test changes in both chromium and webkit. Simply type: git try -b BOT --webkit WEBKIT_BRANCH CHROMIUM_BRANCH A patch containing the diffs of src (against CHROMIUM_BRANCH) and src/third_party/WebKit (against WEBKIT_BRANCH) will be submitted to the try bots of your choice. The --webkit branch option is actually a syntax sugar to an even more powerful option: --sub_rep PATH BRANCH. This option can be used multiple times to specify a series of git sub-repositories to include in the try. Special thanks for Evan Martin and Marc-Antoine Ruel for helping me land this enhancement. -Yaar --~--~-~--~~~---~--~~ 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] Goals for the Layout Tests Task Force
Yep. Dirk was the one to suggest bringing it back. I didn't put this in the documentation, but only because I wasn't yet sure whether we'll track them by bug milestone or explicitly using the tag. :DG On Tue, Sep 22, 2009 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: On Tue, Sep 22, 2009 at 10:26 AM, Jeffrey Chang jeffr...@google.com wrote: Fix all Windows layout tests: make test_expectations.txt only contain items that we will never fix, features we have not yet implemented, or bugs less than one week old that are a result of a recent WebKit merge. Set up a public dashboard which tracks the number of failing layout tests over time on the Chromium site. How do you intend to track these numbers? Right now we have no way to distinguish between failures that need fixing versus failures due to unimplemented features. One way would be to use DEFER again. All the support is still there, and the initial code for the tracking dashboard exposes it. It would mostly just work. I propose that we bring back to defer, but use it *only* for tests that fail due to unimplemented features. 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] WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
Today wasn't a happy day for p...@. He did a seemingly innocuous roll that broke the world: selenium, ui tests, layout tests. I am sure it was stressful and probably added unnecessary gray to his hair. Stuff like this happens to WebKit gardeners. We're used to breakages upstream. That's the cost of being unforked, right? The problem however, is that since we unforked, most of these breakages and regressions are caused by fellow teammates. There are two major issues: 1) writers of patches don't mention that the patch is two-sided and will break Chromium if landed prematurely. I don't have to go far for an example. Commit queue bot landed http://trac.webkit.org/changeset/48659 a few minutes ago and broke the canary. This means that the canary will be red all night and any subsequent regressions will either not be noticed or create more complications. 2) writers of patches don't test them properly. In Paul's case, it was http://trac.webkit.org/changeset/48639, again by a teammate, and it looks like the patch wasn't very thoroughly tested -- it showed a few regressions in the canary, but because it had to do with V8 garbage collection, the failures were intermittent and seemingly random. However, landing it on trunk looked like a shrapnel blast. 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? :DG :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
On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain nsylv...@chromium.org wrote: If this is an issue, I am proposing that Webkit merges be done outside peak hours (11am-5pm pacific). This seems backwards. Don't we want to integrate more often so we can catch and fix these issue faster? Ideally, we'll be able to merge with every webkit.org commit once we get the WebKit API in place. Indeed. I would rather see small rolls throughout the day. Trying to accumulate them into larger spans will result in larger blasts. :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: Changes in webkit.gyp
Go Yaar! Thanks for taking on this task. :DG On Fri, Sep 18, 2009 at 10:56 AM, Yaar Schnitman y...@chromium.org wrote: webkit.gyp was re-factored as preparatory work for the webkit chromium port. More information can be found here: http://codereview.chromium.org/212003/show Thanks for everybody who helped me land this one, and stay tuned for more changes soon! --~--~-~--~~~---~--~~ 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 woes
I've had this issue before and found that if I used svn rebase it would sometimes fix it. So I am thinking perhaps instead of git pull, you could attempt doing git fetch first and then git merge? This would do the same thing, except not in atomic op. :DG On Thu, Aug 27, 2009 at 10:49 AM, Nico Webertha...@chromium.org wrote: Didn't help. Oh well, back to my fallback svn client for now. Will create a new git checkout in the new feature. On Thu, Aug 27, 2009 at 9:12 AM, Evan Martine...@chromium.org wrote: Try git gc On Thu, Aug 27, 2009 at 8:27 AM, Nico Webertha...@chromium.org wrote: The pack file truncated theory sounds most likely. Is there any way I could tell git to regenerate the newest N packfiles? On Thu, Aug 27, 2009 at 8:00 AM, Evan Martine...@chromium.org wrote: https://kerneltrap.org/mailarchive/git/2007/7/23/252538 old and maybe obsolete, but has some exposition from Linus On Thu, Aug 27, 2009 at 7:51 AM, Evan Martine...@chromium.org wrote: Aside from basic stuff like running out of disk space, I have no idea what would cause this problem. (It's weird that pread would fail with no such file when its API is to take an open file descriptor.) One workaround might be to try setting this defined, mentioned in the Makefile: # Define NO_PREAD if you have a problem with pread() system call (e.g. # cygwin.dll before v1.5.22). Not exactly sure it's relevant, but from a script that wraps git where this error came up, the author of the script asks are you on OS X? http://groups.google.com/group/repo-discuss/msg/d6b4fd3d8a1677a2 Unfortunately, either Python or Mac OS X is busted. With multiple cores present, we seem to get the result from waitpid() before all of the changes made by the child process are actually visible in the filesystem, so when we start the next child, the next child might be missing modifications it expected to see. On Wed, Aug 26, 2009 at 10:42 PM, Nico Webertha...@chromium.org wrote: Trying to pull: thakis-macbookpro:~/src/chrome-git/src thakis$ git pull remote: Counting objects: 1859, done. remote: Compressing objects: 100% (1267/1267), done. remote: Total 1393 (delta 1087), reused 195 (delta 107) Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done. fatal: cannot pread pack file: No such file or directory fatal: index-pack failed Ideas? The interwebs suggest deleting some file from my .git folder that's not in there. 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] Tales from the test_expectations ...
It's like Tales from the crypt, but less fun and actually scary. I just found out that we wall-papered over about 80-100 tests in fast/repaint dir. I will be removing bad baselines shortly. The bad news is that this bumped our failures to 875 (from 778 this morning). The good news is that they all (and more!) will be fixed once we fix http://crbug.com/8630. I think this case particularly highlights the nature of our layout test woes: there are only a handful of actual problems, splattered over a large area. The best analogy here is an oil spill. And we are all pelicans. :DG P.S.: evmar, eroman: this may be why your attempts to write layoutTestController.display(); for test_shell were so frustrating: the regressions you were seeing might have been false-negatives. --~--~-~--~~~---~--~~ 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-reviews] Re: WebKit deps roll 47797:47804
Tests only pass if they are actually not loading any media. Which is a number of tests, yes. As an alternative maybe we could just agree among all WebKit gardeners to dump the new failures to bug 16779 and not add them to the end of test_expectations? :DG On Thu, Aug 27, 2009 at 1:25 PM, Ojan Vafaio...@chromium.org wrote: -chromium-reviews +chromium-dev Don't we currently pass a large percentage of the LayoutTests/media tests? Won't we lose coverage of these tests by doing this? Maybe it's worth the savings maintenance cost until we have a complete solution for them? Ojan On Thu, Aug 27, 2009 at 11:46 AM, Dimitri Glazkov dglaz...@chromium.org wrote: BTW, about to filter out all LayoutTests/media out for now, skipping them. We can't have codecs for most of these tests, so we (Alpha and myself) decided it's easier to skip them for now. Permanent solution coming in Q4. :DG On Thu, Aug 27, 2009 at 11:42 AM, Ojan Vafaio...@chromium.org wrote: I see what you're saying. I think the best solution here is to just have one line with two bugs listed. This will also help whoever is going to fix the test as they'll be able to easily see all the reason's it's failing. BUG20376 BUG13907 WIN : LayoutTests/media/video-src-remove.html = TIMEOUT FAIL That OK? On Thu, Aug 27, 2009 at 11:02 AM, Jeremy Orlow jor...@chromium.org wrote: Yes, but it's not flaky now. If you'd like, I can move the commented out one down to right after the new version of it. I think what'd be even better is if multiple entries for one layout test didn't cause the script to parse. Or it'd at least be nice if we could list 2 bugs for one test. The commented out one is NOT deadit's another type of failure that is currently overshadowed by the new type of failure. On Thu, Aug 27, 2009 at 10:57 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Aug 27, 2009 at 10:34 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 27, 2009 at 10:31 AM, o...@chromium.org wrote: http://codereview.chromium.org/173555/diff/1/2 File webkit/tools/layout_tests/test_expectations.txt (right): http://codereview.chromium.org/173555/diff/1/2#newcode745 Line 745: //BUG13907 WIN : LayoutTests/media/video-src-remove.html = FAIL Why leave this in commented out instead of just removing it? Well, there's 2 problems with that test. 1) it's flaky and 2) it's failing. Someone fixing 2 doesn't necessarily fix 1. So they'll probably want to add it back into that list when they're finished. It's also documentation. I don't really see any downside. We have a process for dealing with flaky tests. If it passes sometimes and fails sometimes, mark it PASS FAIL. Why is this case an exception? I see two downsides: Now when it fails, it will turn the tree red. If we make a practice of leaving in commented out tests this file becomes even more bloated than it is now. --~--~-~--~~~---~--~~ 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 test dashboard
Great work, dude. Seriously good stuff. I'll be digging through this tomorrow. Now, how do I change the theme on this thing? ;P :DG On Mon, Aug 24, 2009 at 6:42 PM, Ojan Vafaio...@chromium.org wrote: A first version of the layout test flakiness dashboard is up. http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html Some of the key features: updates roughly as quickly as the bots have run the tests (no post-processing, stdio parsing or crons) sortable by any column include flakiness builder + sort order permalinks (i.e. you can copy-paste URLs for a given builder + sort order) highlights tests with missing expectations (i.e. the test passed, but is marked only as failing) prints out test run times for tests that took 1 second shows the expectations for a test on all platforms Taking a look at the dashboard, you can immediately see a couple things: A bunch of cases where we currently have the missing expectations for a test. For example, LayoutTests/accessibility/plugin.html fails on Windows, but is only listed as failing on the Mac. We have a few dozen very slow tests that considerably slow down how long the tests take to run. How do you get this awesomeness for UI tests, unittests, etc? It's actually *really* easy. Someone just needs to add something to the test runners for those test types that spits out JSON files in the right format and copies them to the appropriate place. Let me know if you're interested in adding support for a new test type. Known issues: The JS that generates the page could stand to be faster. The windows builders have a bunch of junk entries with windows style paths. Ignore them for now, they'll gradually fall off the end of the tests tracked by the dashboard. Only the tests with unix style paths should be looked at. If you have bugs or feature requests. Please file them at crbug.com and CC me. One feature request that I have is to also highlight cases where we list an expectation for a test that never happens (e.g. the test is listed as PASS CRASH FAIL, but has never crashed. 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: Handling layout test expectations for failing tests
On Sat, Aug 22, 2009 at 9:51 PM, Jeremy Orlowjor...@chromium.org wrote: It might be worth going through all the LayoutTest bugs and double check they're split up into individual root causes (or something approximating that). I'll try to make time to do a scan in the next week or so, but it'd be great if anyone else had time to help. :-) I've been doing this last week. Maybe we could figure out how to do this in parallel on Monday? :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: Handling layout test expectations for failing tests
I understand the resistance to implement yet another bit of process and effort around layout tests. I really do. However, I found some merit in Dirk's idea -- it allows us to clearly see the impact of a regression. Sadly, I can't come up with a specific example at the moment, but let me pull one out of my ... hat, based on previous experiences. Let's say we had a regression in JSON parsing. But since we already fail parts of the LayoutTests/fast/js/JSON-parse.html, we wouldn't notice it. Especially with DOM bindings, there are tons of tests like this -- we pass only parts of them, so we wouldn't know when our changes or commits upstream introduce regressions that we really ought to be noticing. It's kind of like marking layout tests as flakey: there's no way to determine whether the flakiness is gone other than by recording some extra information. So to me at least, the benefit of this type of solution is not near-zero. My only hesitation comes from having to decide whether we should stop and implement this rather than dedicate all of our resources to plowing ahead in fixing layout tests and driving the number to 0 (and thus eliminating the need for this solution). :DG On Fri, Aug 21, 2009 at 6:43 PM, Ojan Vafaio...@chromium.org wrote: On Fri, Aug 21, 2009 at 4:54 PM, Peter Kasting pkast...@chromium.org wrote: On Fri, Aug 21, 2009 at 4:50 PM, Dirk Pranke dpra...@chromium.org wrote: This is all good feedback, thanks! To clarify, though: what do you think the cost will be? Perhaps you are assuming things about how I would implement this that are different than what I had in mind. Some amount of your time, and some amount of space on the bots. Also, some amount of the rest of the team's time to follow this process. 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] Free to good home: a chunky, non-trivial task of decoupling Chromium WebKit port from Chromium build system.
If you don't commit to WebKit, you can stop reading now. I am looking for someone to own a fairly large-sized task: bringing up WebKit-side build of our port to life. The bug for it is here: https://bugs.webkit.org/show_bug.cgi?id=28396 The big picture is here: https://trac.webkit.org/wiki/Chromium I started writing down ideas/thoughts in the comments. Any takers? :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] Star of the day
I thought this is something I should mention here: This change: http://src.chromium.org/viewvc/chrome?view=revrevision=23244 reduced the number of crashes on Mac from 13-15 with high degree of flakiness to a very consistent 2. pkasting, this is your man. :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: Clobbering
The culprit here was the change to the CodeGeneratorV8.pm. It looks like we should somehow trigger clobber of of rule_binding.py when that happens. :DG On Mon, Aug 10, 2009 at 11:24 PM, Jeremy Orlowjor...@chromium.org wrote: They were both WebKit deps rolls. The latter one was caused by an .idl file that changed. The former, I don't know off the top of my head. Here's the chromium review: http://codereview.chromium.org/165278 Here are the files that changed: http://trac.webkit.org/changeset?new=47...@trunkold=46...@trunk Here's the error visual studio gave: DerivedSourcesAllInOne.cpp C:\b\slave\win\build\src\chrome\Debug\obj\webcore\bindings/V8Document.cpp(1003) : error C2039: 'v8ElementEventHandlerAccessorGetter' : is not a member of 'WebCore::V8Custom' C:\b\slave\win\build\src\third_party\WebKit\WebCore\bindings\v8\custom\V8CustomBinding.h(94) : see declaration of 'WebCore::V8Custom' On Mon, Aug 10, 2009 at 11:17 PM, Bradley Nelson bradnel...@google.com wrote: We currently have a hack of sorts in mind (well an issue filed on gyp) that would cover a larger class of settings changes (the worst handled by vstudio directly). The idea is to have gyp generate a text file full of settings garp which would be an additional dependency of each project. There are of course other dependency flaws (sgk is working on a long running validation build that would look for missing links in the chain) that are just due to mistakes in the gyp files. I would be curious which kind of dependency issue these latest ones were (can someone point me at the CLs?, been on nacl/o3d buildbot stuff of late). -BradN On Mon, Aug 10, 2009 at 11:00 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 10, 2009 at 10:45 PM, Aaron Boodman a...@chromium.org wrote: Such a system does not help when people sync your change. We should invest the effort we would expend building this system fixing the dependency issues. gclient could be made to obey it as well. But I agree, it's a hack. Barring that, we have a hack that we do where for resource files we make a whitespace change to the corresponding .gyp. We could automate this by having a presubmit check that enforces this. Better than nothing. We also have the hack for grd files that deletes all the associated .h files. Something like that might work here as well. How hard would it be to make the system actually understand the dependencies? Is visual studio really just too dumb to understand? --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
2. The show stopper for any implementation of this feature is that the machines running the layout tests don't have the pdbs for test_shell. Since the binary is built on another machine, it was too slow to copy the pdbs from one machine to another. If you guys think it's important, and can take the ~30-60 more seconds to cycle the bots, then we can copy them too, and the feature would work. I'm not really sure what the right answer is. It sure would be nice if we didn't need to use a tool to decode the call stacks of crashed layout tests. I kind of feel like an additional 30-60 seconds isn't going to be a big deal on these bots, but maybe it is. What do people think? We should probably implement a suppression mechanism here as well, so that the crashes due to current work in progress (Mac plugins, workers, etc.) don't take any time. This should minimize the impact. :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: Stack traces on layout test crashes
Somebody please run with this! :) :DG On Fri, Aug 7, 2009 at 8:45 PM, Darin Fisherda...@chromium.org wrote: On Fri, Aug 7, 2009 at 8:39 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Aug 7, 2009 at 8:45 PM, Jeremy Orlow jor...@chromium.org wrote: Has anyone ever looked into printing out stack traces when layout tests crash? Of the couple layout test crashes I've investigated, I think most could have been solved just by having a stack trace. I'm not really sure what's involved or if anyone's looked into this, which is why I'm asking. This could be especially helpful for flaky tests that crash. I don't remember anyone having looked into this. I agree that this would make tracking down and fixing these issues immensely easier, especially for tests that only sometimes crash. Ojan I've wanted this for a very long time. I think there might be a bug on it. At any rate, we now have a nice utility in base/debug_util.h that can provide a stack trace. I would love to see crash stacks on the buildbot. It would probably help us eliminate a lot of flakiness! -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: PSA: irc awareness [Was: Trick question: Who is responsible for repairing a red tree?]
On Colloquy (+ Growl), I set the toast with my name mentioned to never expire. So it's always there unless I X it out. :DG On Wed, Aug 5, 2009 at 7:25 PM, Dirk Prankedpra...@google.com wrote: I would love to enable that feature ... anyone know how to do that for Adium on the Mac (IRC support is new in the 1.4 beta)? Failing that, Colloquy? -- Dirk On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruelmar...@chromium.org wrote: Most irc clients have an option to beep, flash or shutdown your computer when your nick is mentioned on a channel. It may not be enabled by default so please enable this. Ask around if you can't find how to enable this. Thanks, M-A On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegel mac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegel emailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ 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: Flakiness. Please help.
Ojan is working on the tool for the layout tests. First bits are already checked in. :DG On Wed, Aug 5, 2009 at 10:10 PM, Eric Seidelesei...@chromium.org wrote: Do we have a list of flakey tests? I feel like we used to have one... On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting pkast...@google.com wrote: THIS MAIL APPLIES TO YOU Flakiness is growing. Smash it before it gets bigger, and keep it smashed. *** The MOST IMPORTANT section in this gigantic mail: PLEASE spend some of every workday (or each week at least, if you can't spare time each day) looking at test failures, flakiness, valgrind/purify/coverity bugs, crashes, and/or memory bugs. Make it a goal to get an average of one line in the test-expectations file removed each day. If you're a Googler, put it on your OKRs (now, not sometime tomorrow). * DON'T wait for someone to assign bugs to you or ask for your help * DON'T wait for a team fixit week (those haven't worked) * DON'T wait for someone else to solve the problems * DON'T wait until after your current project is finished * DON'T wait until you have worked on WebKit HELP, even if it's just a little, even if it's not your core competence. We currently have hundreds upon hundreds of failing or flaky tests. We can dramatically reduce this quickly but ONLY IF YOU HELP. This is an investment not only in the quality of Chrome but in the team's ability to move fast, so help here doesn't just improve the quality of Chrome, but also the derivative of the quality :) (If you do not know how to do anything above and need handholding, e-mail me and I will help you. It's OK to be ignorant.) *** Next, how you should help keep the tree green at all times: * If you ever look at the buildbot and see red, and there's no explanation in the build status, ask what's going on on #chromium. Ping the sheriffs specifically (they're listed in the upper-right corner). If you do not get an answer about ownership within a few minutes, close the tree (if you have the rights to) or ask someone to close it. THE TREE SHOULD NOT BE OPEN WITH RED THAT NO ONE OWNS. Help the sheriffs out with this -- they can't watch every second. Closed trees suck; unowned bustage sucks more. Be hard-nosed. * Yes, even purify, valgrind, and reliability bot redness. If you can't figure out what to do with these, try pinging erikkay for purify issues and huanr for reliability issues. (Not sure who a good general valgrind contact is.) * If you ever look at the buildbot and see orange (unexpected pass), especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the calendar is linked from the top of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't know whether it's world-readable). If he wasn't aware of it, agree between you on who will deal with it. Orange alone is not reason to close the tree, but it should NOT be ignored. * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE. If they're really fixed by someone's commit, that should be easy to determine. Otherwise, they're flaky, and we NEED to mark them as such, not just leave them. *** Finally, how to help if the LayoutTest bots are red or orange: (1) Try and determine if the test(s) are consistently passing/failing unexpectedly, or if they're flaky. Make sure you look at all the different bots to see which OSes are affected. (2) Update src/webkit/tools/layout_tests/test-expectations.txt. Look for the test(s) in question. Often, flaky tests will already be in there as failing or flaky for one OS, and need to have more added; or they will be marked flaky (FAIL PASS) and need CRASH added. If they're not there, add a line. (3) Ensure the test(s) have a bug on file. Note the bug on the expectation. (4) If any tests are crashing (flaky or not), they're high-priority and someone needs to triage them. Today, dglazkov was WebKit sheriff and was having me mark these bugs as P1, Mstone-3, owner:dglazkov. I'm not sure whether the Right Thing is to assign them to the WebKit sheriff or still to him (feel free to comment, dglazkov!). Why are these P1? Because until we prove they can't affect Chrome itself, they potentially can, and Chrome crashes are always P1. They affect stability and security both. (5) If you have commit rights, go ahead and TBR test-expectations changes you're confident of. I even suggest using --force if the tree is closed. Updating expectations is like fixing bustage, it helps the tree go green faster and thus is almost always desirable. If you don't have commit rights, send your review to the WebKit sheriff. *** Your reward for reading this far: * At the end of the quarter, I will nominate for a peer bonus every Googler who puts something meaningful about flakiness/test failures/the other stuff above on their OKRs, accomplishes it, and sends me a note pointing that out. * At the end of the quarter, I will nominate for commit access
[chromium-dev] Re: V8 bindings are now fully upstreamed!
Thanks for checking on this! I made the changes. :DG On Wed, Jul 29, 2009 at 3:30 PM, Evan R. Murphyevanrmur...@gmail.com wrote: Thanks to all who worked on this, and congratulations on the success. Can somebody with the permissions please update How Chromium Displays Web Pages [1] to reflect these changes? From that doc: 'At the lowest level we have our WebKit port. This is our implementation of required platform-specific functionality that interfaces with the platform-independent WebCore code. These files are located in /webkit/port which has a hierarchy similar to the WebCore tree. Much of our port is not actually OS-specific: you could think of it as the Chromium port of WebCore.' Regards, Evan R. Murphy On Jul 17, 12:42 pm, Nate Chapin jap...@google.com 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: 2 Questions about Npapi (and flash in particular)
On Sun, Aug 2, 2009 at 8:17 PM, nakroyoav.zilberb...@gmail.com wrote: This is mostly related to problems people have in the help forum 1- you fork a process for npapi plugins, but many people report that if they have a bookmark folder with loads of flash content, they get an 'Aw Snap' or the lucky ones get OUt of Script memory Got any actual repro cases? :) That would be very helpful. :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: How to exclude src/third_party/WebKit/LayoutTests when checkout chromium source code
Are you volunteering? ;)
http://spreadsheets.google.com/ccc?key=piGkUUMLW-PNUzuhTCzm4NQ
:DG
On Thu, Jul 16, 2009 at 9:43 AM, Jeremy Orlowjor...@chromium.org wrote:
Maybe those should be moved out of the source tree (into deps) so that they
can be excluded?
On Thu, Jul 16, 2009 at 9:23 AM, Victor Wang vict...@chromium.org wrote:
By the way, in your client, you won't be able to exclude the
whole src/webkit/data/layout_tests directory, only the LayoutTests
subdirectory can be excluded, you will still pull other subdirectories like
chrome, platform, pending etc.
On Thu, Jul 16, 2009 at 9:17 AM, Victor Wang vict...@chromium.org wrote:
I don't get third_party/WebKit/LayoutTests by excluding it in my
.gclient, not sure why it doesn't work for you. here is custom_deps section
in my .gclient:
custom_deps : {
# To use the trunk of a component instead of what's in DEPS:
#component: https://svnserver/component/trunk/;,
# To exclude a component from your working copy:
#data/really_large_component: None,
src/third_party/WebKit/LayoutTests: None,
src/webkit/data/layout_tests/LayoutTests: None,
},
On Wed, Jul 15, 2009 at 7:38 PM, James Howlett
james.l.howl...@gmail.com wrote:
How to exclude src/third_party/WebKit/LayoutTests when checkout
chromium source code?
I have added this to my .gclient
src/third_party/WebKit/LayoutTests: None,
src/webkit/data/layout_tests: None,
the directory src/webkit/data/layout_tests was excluded, but diectory
src/third_party/WebKit/LayoutTests is NOT excluded. Everytime, i
remove src/third_party/WebKit/LayoutTests, and then do a gclient sync,
it pulls does all the source again.
Can you please tell me how to exclude both directories?
Thank you.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] WebCore.gypi and JavaScriptCore.gypi now online.
Dear All, Just a few hours ago, I switched over webkit.gyp to pull the list of WebCore and JavaScriptCore files from upstream-living WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi, respectively. This change should alleviate a lot of pain for WebKit gardeners and those landing two-sided patches. In many cases, this will eliminate the need for two-sided patches. Please let me know if you are encountering weird problems and/or deep spiritual experiences after syncing past this change. :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: Let's make build system history!
bump. On Wed, Feb 25, 2009 at 2:27 PM, Mark Mentovaim...@chromium.org wrote: Over the past month, some of us have been working on a not-so-well-kept secret project to create a build system system. Our goal is to have something Generate Your Projects (GYP) in a variety of formats, all from the same source. Today, we're ready to allow Mac developers to begin testing this experimental system. If you're on a Mac, I encourage you to try this out. From the src/build directory in a Chromium working copy, run: ../tools/gyp/gyp and in less than 10 seconds, a whole bunch of new Xcode projects will be generated for you. For the most part, they follow the same structure as the existing Xcode projects you're familiar with, so if you've been working with chrome.xcodeproj or test_shell.xcodeproj, you'll have no problem finding and using chrome_gyp.xcodeproj and test_shell_gyp.xcodeproj. Similarly, build results go into xcodebuild_gyp. The _gyp suffix is temporary, and keeps us from clobbering the old checked-in project files. Right now, Generating Your Projects is voluntary and manual. If a .gyp file changes because you've edited it or because of a sync, you'll need to re-run the above command to regenerate your project files. Before we go live, we'll add a hook to gclient to Generate Your Projects automatically when .gyp files change during a sync. I believe that the generated projects are now at parity with the old checked-in project files, but the .gyp files do suffer from becoming outdated pretty quickly. If you're adding or removing files from the tree, I'd appreciate it if you could help me out by making the appropriate modifications to our .gyp files. For the time being, please Cc me on all reviews involving a .gyp file. I think you'll all find that maintaining .gyp files is far easier than working with Xcode projects. We have some work-in-progress documentation available at http://code.google.com/p/gyp/w/list to help orient yourself. I'll be working more on the documentation in the days to come. We've also made significant progress on gyp-based Visual Studio, SCons, and Makefile generation, so those of you who aren't using Macs won't miss out for too long. Have fun! 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: Moving LayoutTests to src/third_party/WebKit
Right. Victor is just switching the tests to reside where they needed to be, not dealing with test results. Test results is somewhat of a longer story and we're not tackling this yet. :DG On Fri, Jul 10, 2009 at 12:07 PM, Victor Wangvict...@chromium.org wrote: On Fri, Jul 10, 2009 at 11:11 AM, Ryosuke Niwa rn...@google.com wrote: On Thu, Jul 9, 2009 at 3:09 PM, Victor Wang vict...@chromium.org wrote: If you DO NOT check out chromium source code, you can stop reading. What's the change? To reduce people's confusion about the LayoutTests directory, I am moving it from src/webkit/data/layout_tests/LayoutTests to src/third_party/WebKit/LayoutTests. For details of this request, see issue: http://code.google.com/p/chromium/issues/detail?id=8765 Does this mean that in the future, all expected results will be in WebKit? i.e. we no longer need to update Chromium tree whenever WebKit changes expected results. I think eventually we will get rid of chrome and upstream platform. For now, I just move the LayoutTests directory. Ojan or Dimitri can correct me if I am wrong. Ryosuke --~--~-~--~~~---~--~~ 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: 2000 errors building WebCore bindings!
Apply this locally, if you want to get rid of them:
diff --git a/WebCore/bindings/scripts/IDLParser.pm
b/WebCore/bindings/scripts/IDLParser.pm
index c4cb041..0a6832f 100644
--- a/WebCore/bindings/scripts/IDLParser.pm
+++ b/WebCore/bindings/scripts/IDLParser.pm
@@ -75,7 +75,7 @@ sub Parse
print | *** Starting to parse $fileName...\n |\n unless $beQuiet;
-open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map { -D$_
} split(' ', $defines)), $
+open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map {
s///g; -D$_ } split(' ', $defi
close PP_IN;
my @documentContent = PP_OUT;
close PP_OUT;
Unfortunately, this is probably not the proper fix -- it deals with
the symptom, not the cause.
:DG
On Mon, Jul 6, 2009 at 7:29 AM, Evan Martine...@chromium.org wrote:
http://code.google.com/p/chromium/issues/detail?id=15904
Something went wrong with quoting when some v8-related script was
upstreamed. Dimitri's working on it.
On Mon, Jul 6, 2009 at 7:18 AM, Mike Pinkertonpinker...@chromium.org wrote:
When I try to build today, I get 2000 errors of the form:
command line:1:1: error: macro names must be identifiers
when building WebCore bindings. Others have complained of similar
errors on Linux. What's going on here? Reports are that it seems to
still build correctly, but this really throws XCode for a loop.
This was introduced at r19816.
--
Mike Pinkerton
Mac Weenie
pinker...@google.com
--~--~-~--~~~---~--~~
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: 2000 errors building WebCore bindings!
I agree -- if weren't such a Python n00b I'd already have a patch. I
am looking through it now
:DG
On Mon, Jul 6, 2009 at 8:19 AM, Mark Mentovaim...@chromium.org wrote:
= needs to be quoted if it occurs in the first word passed to the
shell (or, if the first word was a variable assignment, the second
word, and so on). EncodePOSIXShellArgument doesn't know or care
whether it's working with the first word or a subsequent one.
I'm pretty much convinced that whatever is going on here ought to be
dealt with in webkit/build/rule_binding.py.
Mark
Ben Laurie wrote:
On Mon, Jul 6, 2009 at 3:43 PM, Dimitri Glazkovdglaz...@google.com wrote:
Apply this locally, if you want to get rid of them:
diff --git a/WebCore/bindings/scripts/IDLParser.pm
b/WebCore/bindings/scripts/IDLParser.pm
index c4cb041..0a6832f 100644
--- a/WebCore/bindings/scripts/IDLParser.pm
+++ b/WebCore/bindings/scripts/IDLParser.pm
@@ -75,7 +75,7 @@ sub Parse
print | *** Starting to parse $fileName...\n |\n unless $beQuiet;
- open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map { -D$_
} split(' ', $defines)), $
+ open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map {
s///g; -D$_ } split(' ', $defi
close PP_IN;
my @documentContent = PP_OUT;
close PP_OUT;
Unfortunately, this is probably not the proper fix -- it deals with
the symptom, not the cause.
The cause is gyp.common.EncodePOSIXShellArgument, which thinks the
presence of an '=' means the argument needs to be quoted. I am less
than convinced this is really true, no matter what POSIX says :-)
:DG
On Mon, Jul 6, 2009 at 7:29 AM, Evan Martine...@chromium.org wrote:
http://code.google.com/p/chromium/issues/detail?id=15904
Something went wrong with quoting when some v8-related script was
upstreamed. Dimitri's working on it.
On Mon, Jul 6, 2009 at 7:18 AM, Mike Pinkertonpinker...@chromium.org
wrote:
When I try to build today, I get 2000 errors of the form:
command line:1:1: error: macro names must be identifiers
when building WebCore bindings. Others have complained of similar
errors on Linux. What's going on here? Reports are that it seems to
still build correctly, but this really throws XCode for a loop.
This was introduced at r19816.
--
Mike Pinkerton
Mac Weenie
pinker...@google.com
--~--~-~--~~~---~--~~
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: 2000 errors building WebCore bindings!
http://codereview.chromium.org/155089
:DG
On Mon, Jul 6, 2009 at 8:33 AM, Mark Mentovaim...@chromium.org wrote:
I can help you out this afternoon if necessary.
Dimitri Glazkov wrote:
I agree -- if weren't such a Python n00b I'd already have a patch. I
am looking through it now
:DG
On Mon, Jul 6, 2009 at 8:19 AM, Mark Mentovaim...@chromium.org wrote:
= needs to be quoted if it occurs in the first word passed to the
shell (or, if the first word was a variable assignment, the second
word, and so on). EncodePOSIXShellArgument doesn't know or care
whether it's working with the first word or a subsequent one.
I'm pretty much convinced that whatever is going on here ought to be
dealt with in webkit/build/rule_binding.py.
Mark
Ben Laurie wrote:
On Mon, Jul 6, 2009 at 3:43 PM, Dimitri Glazkovdglaz...@google.com wrote:
Apply this locally, if you want to get rid of them:
diff --git a/WebCore/bindings/scripts/IDLParser.pm
b/WebCore/bindings/scripts/IDLParser.pm
index c4cb041..0a6832f 100644
--- a/WebCore/bindings/scripts/IDLParser.pm
+++ b/WebCore/bindings/scripts/IDLParser.pm
@@ -75,7 +75,7 @@ sub Parse
print | *** Starting to parse $fileName...\n |\n unless $beQuiet;
- open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map { -D$_
} split(' ', $defines)), $
+ open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map {
s///g; -D$_ } split(' ', $defi
close PP_IN;
my @documentContent = PP_OUT;
close PP_OUT;
Unfortunately, this is probably not the proper fix -- it deals with
the symptom, not the cause.
The cause is gyp.common.EncodePOSIXShellArgument, which thinks the
presence of an '=' means the argument needs to be quoted. I am less
than convinced this is really true, no matter what POSIX says :-)
:DG
On Mon, Jul 6, 2009 at 7:29 AM, Evan Martine...@chromium.org wrote:
http://code.google.com/p/chromium/issues/detail?id=15904
Something went wrong with quoting when some v8-related script was
upstreamed. Dimitri's working on it.
On Mon, Jul 6, 2009 at 7:18 AM, Mike Pinkertonpinker...@chromium.org
wrote:
When I try to build today, I get 2000 errors of the form:
command line:1:1: error: macro names must be identifiers
when building WebCore bindings. Others have complained of similar
errors on Linux. What's going on here? Reports are that it seems to
still build correctly, but this really throws XCode for a loop.
This was introduced at r19816.
--
Mike Pinkerton
Mac Weenie
pinker...@google.com
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Full pass of acid3.
As of r19910 (and with --enable-remote-fonts flag), we now fully pass the acid3 test. Thanks to brettw for his patience and to pkasting for guilting me into fixing this the right way. :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: MYTH: WebKit uses design docs
I don't see anything wrong with publishing design docs on webkit-dev. Just don't proselytize :) :DG On Mon, Jun 29, 2009 at 11:40 AM, Jeremy Orlowjor...@chromium.org wrote: On Mon, Jun 29, 2009 at 11:07 AM, David Levin le...@chromium.org wrote: 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. True. I guess WebKit guys have historically been pretty sensitive to us pushing our ways upon them. Maybe we can continue circulating design docs for work in WebKit on this mailing list, but keep them on the down low on the WebKit mailing list? Maybe post links in bugs, but only bring them up on the mailing list when there's specific issues to discuss? 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] WebKit Sheriffing Documentation Update
Based on our experiences from the past few weeks of rolling, I updated the WebKit Integration documentation: http://sites.google.com/a/chromium.org/dev/developers/how-tos/webkit-merge-1 They key takeaways are: 1) roll often, in small increments 2) pay attention to actual changes you're rolling in and update test results. 3) don't hesitate to ask for help in case for breakage, but make sure to roll to the last green revision. :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: Landing two sided patches
Yes, we're working feverishly (is that a good word for this? :) to make this situation a bit less hard. However, in the meantime, the process could go like this: 1) Make sure the canary had a green run. This would really help the WebKit gardener to know which revision to roll up to. 2) Land your patch upstream. There's no need to close the tree -- the only thing you'll break is the canary bot. 3) Let the gardener to roll up to last green revision 4) In parallel, prepare a patch that rolls deps to your revision, including your fix. Since the gardener's roll is green, you shouldn't have any breakage. If you do, it's your fault :) --- this is basically the key to sanity. Don't land your one-revision roll if it breaks your local compile. 5) Let the gardener land their patch 6) Sync and land your patch right after the gardener lands. If you have more than one of these, rinse and repeat. I don't think it is a good idea to land multiple breakages and then sort them out downstream. The situation is much muddier when you are already dealing with multiple breakages upstream. That was the case early this week. In this case, the gardener: 1) finds the breaking rev by studying the canary and trac.webkit.org, 2) checks that the rev before indeed builds, and sort out whatever test regressions it may have locally 3) Lands the roll 4) Depending on the nature of the breakage, calls the expert. I am working on a list that will include various parts of our port, but for now you could just ping levin, darin, or me (in that order ;) 5) The expert will do a one-rev roll, fixing the breakage. Basically, the idea is to let the gardener roll while green, and make one-rev rolls/fixes for bustage. For gardeners: I can not emphasize enough that it is *much* easier to roll deps many times a day in small, green increments. Use the canary, it'll tell you the revs that are safe to roll. Otherwise, you'll be landing large swaths full of red and wonder at the fireworks in amazement. Don't wait for the end of the day. Another note: today, most of the layout test failures you'll see after a merge are either new tests or changes in expectations that just need rebaselining. The regressions should be rare and cause for alarm. Please look at the tests, failing on the canary. Rebaseline or file bugs if we're not passing for a good reason. Don't sweep them under the test_expectations rug. It is *much* harder to dig through the hundreds of lines of failures, trying to figure this out after the fact. Hope this helps. Sorry this is a bit too long, I am trying to get to actually putting this in a more stable format, and this time is as good as any. :DG On Thu, Jun 25, 2009 at 4:46 PM, Darin Fisherda...@chromium.org wrote: I suspect there are things we can do that will avoid much of the need to do a Chromium side change in unison with a WebKit side change. #1 is probably upstreaming some .gypi files so that the set of files to build can be stored in svn.webkit.org. The WebKit API will also help, and completing the upstreaming of V8 is another biggie. -Darin On Thu, Jun 25, 2009 at 3:53 PM, Adam Langley a...@chromium.org wrote: Dear Lords of the WebKit, I come to you seeking guidance about how best to avoid the mess that the tree got into this afternoon. Japhet and I both had two sided patches to land (where one needs to land both the WebKit and Chromium sides together). We emailed the merger for the day (jianli) and asked him to email us when the merge landed. He did so and I closed the tree. japhet and I both started landing upstream. I landed r45191 and the Chromium side (including a large DEPS roll) in r19287. japhet landed upstream in r45193 and r19291. The tree went red because V8IsolatedWorld had landed upstream in the mean time and needed an include file changed because of japhet's upstreaming. I TBRed upstream (r45201) and rolled DEPS (r19295). However, that pulled in several other upstream patches, one of which broke the build in another way! So I TBRed upstream to fix that (r45203) and rolled DEPS again (r19298). Thankfully, due to fleetness of keyboard, no other patches landed upstream in the mean time. In the past, for small patches, I've emailed the WebKit merger with the patch to land. However, for larger patches, esp those which might have conflicts, this seems unfortunate. It also breaks the SVN log/blame for the future. How best to deal with this now that we pull directly from upstream? Should I just have reverted Chromium at the first sign of trouble? AGL --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
Can we put this in a bug for easier trackage? :DG On Mon, Jun 22, 2009 at 5:58 AM, Evan Martine...@chromium.org wrote: While we're wishing, I'll add that verifying this should be added to the presubmit script (if you touched any layout tests). On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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-dev] Changing our IDL syntax to get closer to WebIDL
Amen. I am working on it :) First step -- teach our code generator to understand IDL in the same way JSC does. :DG On Mon, Jun 22, 2009 at 12:02 PM, Aaron Boodmana...@chromium.org wrote: One thing I'd really like to see is a reduction in the amount of custom bindings code. I am terrified by the number of subtle bugs that must be hiding in there. It seems like teaching the IDL parser and code generator on the WebKit side about more WebIDL-isms would help with this, since a lot of the custom bindings deal with things like function references. - a On Mon, Jun 22, 2009 at 11:25 AM, Eric Seidelesei...@chromium.org wrote: I'm still not enthused about WebKit having 2 different JavaScript engines. ;) But that's a discussion for another time... -eric On Mon, Jun 22, 2009 at 10:54 AM, Jeremy Orlowjor...@chromium.org wrote: I'm not so sure [1]but we can ask. J [1] http://lists.macosforge.org/pipermail/webkit-dev/2009-May/007960.html 1) We weren't super enthusiastic about the master WebKit tree trying to support two different JavaScript engines. But we finally agreed when the Chrome folks said this was a hard requirement to merge, and promised they would take on absolutely 100% of the maintenance burden and impose no cost on the rest of the WebKit project. As a result: On Mon, Jun 22, 2009 at 10:48 AM, Eric Seidel esei...@chromium.org wrote: If our binding code is already upstream by then, Darin may be able to keep Chromium building throughout the process. https://bugs.webkit.org/show_bug.cgi?id=26567 On Mon, Jun 22, 2009 at 9:53 AM, Jeremy Orlowjor...@chromium.org wrote: FYI from the webkit mailing list. We'll probably want to prepare a similar CL for our binding generating code and whoever is doing the merges should look out for this change being landed. J On Sun, Jun 21, 2009 at 10:46 PM, Darin Adler da...@apple.com wrote: The IDL file format we use to generate our bindings has some things in common with WebIDL and many differences. There are extended attributes we use that exist in WebIDL but with a different name. As a first step in making our IDL syntax be as close to the WebIDL standard as possible, I’d like to move our extended attributes so they go in the appropriate place in the syntax. Ours currently come later in an attribute definition; WebIDL puts them before the attribute definition. I have a patch to do this in this bug https://bugs.webkit.org/show_bug.cgi?id=26398. Currently the patch contains the code changes to make the binding machinery parse the new syntax, and a couple hand-converted files. I plan to write a script to convert all the IDL files to the new syntax. Should be easy. Not sure about what impact this will have for V8. -- Darin ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-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] Tagging WebKit bugs with [Chromium]
I think this is a really good idea, something Maciej has been doing for us in bugs.webkit.org: Anytime you create a WebKit bug that's specific to Chromium port, please add [Chromium] prefix to the bug title. :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: V8 Generated Constructors
You're almost there. You also need to make sure to register it in v8_proxy.cpp (look for Image as a pattern to follow). BTW, with gyp, dependencies in bindings are pretty robust. No need to clobber anymore. :DG On Thu, Jun 18, 2009 at 4:05 PM, kylepky...@chromium.org wrote: Ok, so. So far I've created a new file V8HTMLAudioElementConstructor.cpp and modeled it off V8HTMLImageElementConstructor.cpp (changing all images to audios, plus modified V8CustomBinding.h and webkit.gyp. Change is here: http://codereview.chromium.org/132036 But I'm still getting TypeError: Illegal constructor when I try to call the audio constructor. Is there another hook I'm missing? On Jun 16, 11:47 am, Dimitri Glazkov dglaz...@google.com wrote: A good place to start would be to look at existing *Constructor.cpp files in WebCore/bindings/v8 and see how they are hooked in (like Image constructor). Also, you have dimich and levin in close proximity you who have added a V8 constructor or two in the past (I think). ;DG On Mon, Jun 15, 2009 at 5:47 PM, Kyle Preteky...@chromium.org wrote: Hey I'm looking into these layout tests: LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-constructor.html LayoutTests/media/constructors.html and I need to know how constructors are generated. The failures all appear to be due to the Audio constructor, specifically: TypeError: Illegal constructor 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: V8 Generated Constructors
A good place to start would be to look at existing *Constructor.cpp files in WebCore/bindings/v8 and see how they are hooked in (like Image constructor). Also, you have dimich and levin in close proximity you who have added a V8 constructor or two in the past (I think). ;DG On Mon, Jun 15, 2009 at 5:47 PM, Kyle Preteky...@chromium.org wrote: Hey I'm looking into these layout tests: LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-constructor.html LayoutTests/media/constructors.html and I need to know how constructors are generated. The failures all appear to be due to the Audio constructor, specifically: TypeError: Illegal constructor 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] Resurrecting the JSC build.
Team, Now that we're unforked, we want to concentrate on eliminating layout test failures. Through the magic of the WebKit merge, we've accumulated quite a few. Today, we expect around 400 failures, which is not a good number by any stretch. As one of the ways to help determine the source of the failures, I propose that we resurrect the JSC build (and builder), so that we can say with a fair degree of certainty if the cause is in the V8 bindings. Those of you who were involved in maintaining a JSC build of Chromium before may experience painful flashbacks and shortness of breath. My hope is that this time around we should have easier time, since we're unforked and the Script* abstractions are pretty well-defined to keep most of the nasties at bay. Additionally, having gyp is certainly a super-great help. Based on the IM/hallway conversation, Dave Levin, Dmitry Titov, myself and possibly a few others might be interested in helping out with the project. We don't want this to be more than a 10% effort on our parts. Since we hope to have a JSC build bot and ideally a canary bot, we may need some help from the infrastructure gods. So, do you think that resurrecting the JSC build is a: a) terrible idea b) great idea c) whatcha talking bout, Willis? :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: V8DOMMap
/me raises hand sheepishly. Whatcha need? :) :DG On Wed, Jun 3, 2009 at 5:37 PM, Adam Barth aba...@chromium.org wrote: Who's a good contact for V8DOMMap? It's probably going to need some surgery to support isolated user scripts, and I want to make sure I'm not screwing it up. Thanks, Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: [client-tools-dev] Re: [chromium-dev] webkit now building with gyp on Windows
Stee-ven! Stee-ven! Stee-ven!
:DG
On Fri, May 8, 2009 at 9:36 AM, Bradley Nelson bradnel...@google.com wrote:
Congrats steven! Excellent work!
-bradn
On May 8, 2009 8:51 AM, Darin Fisher da...@chromium.org wrote:
FYI, here's the patch I applied to enable /MP:
Index: common.gypi
===
--- common.gypi (revision 15636)
+++ common.gypi (working copy)
@@ -380,6 +380,7 @@
'msvs_disabled_warnings': [4503, 4819],
'msvs_settings': {
'VCCLCompilerTool': {
+ 'AdditionalOptions': '/MP',
'MinimalRebuild': 'false',
'ExceptionHandling': '0',
'BufferSecurityCheck': 'true',
On Fri, May 8, 2009 at 3:27 AM, Steven Knight s...@chromium.org wrote:
The webkit build on ...
--~--~-~--~~~---~--~~
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: No more commits to third_party/WebKit
Not yet. There's a small bunch of people still landing unforkages. :DG On Fri, May 1, 2009 at 8:40 AM, Marc-Antoine Ruel mar...@chromium.org wrote: svn lock? On Fri, May 1, 2009 at 11:35 AM, Dimitri Glazkov dglaz...@chromium.org wrote: We are very, very close to total unforking. In order to facilitate the completion of this process, please refrain from landing any changes in trunk/deps/third_party/WebKit. This holds true even if your patch is already approved upstream. So, to put it simply: NO MOAR THIRD_PARTY/WEBKIT COMMEETS. :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] Performance impact due to unforking ResourceResponse.h
Team, As part of the global WebKit unforking, I will be rolling out shortly the change to ResourceResponse.h that we put in a while back: http://codereview.chromium.org/29007 We have now completed the investigation and there's no need for this fork anymore. As a result, you will see a memory/speed change in the Intl1 cycler. Do not be alarmed. This is a just a trade-off due to more accurate cache accounting. :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: Canary Bot Lives!
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: No more commits to third_party/WebKit
Right. Changes to WebKit/WebKit/chromium are still allowed, because this is not yet upstream. :DG On Fri, May 1, 2009 at 1:11 PM, John Abd-El-Malek j...@chromium.org wrote: Does this also include third_party\WebKit\WebKit\chromium\public\WebKitClient.h? I'm guessing not, since none of those files are in the WebKit repository yet, but just want to double check. On Fri, May 1, 2009 at 8:35 AM, Dimitri Glazkov dglaz...@chromium.org wrote: We are very, very close to total unforking. In order to facilitate the completion of this process, please refrain from landing any changes in trunk/deps/third_party/WebKit. This holds true even if your patch is already approved upstream. So, to put it simply: NO MOAR THIRD_PARTY/WEBKIT COMMEETS. :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
I think it's a great idea and the only drawback I can see is the WTF dependency and the security implications, which shouldn't be anything we couldn't overcome. The biggest challenges IMHO would be: 1) clearly identifying what backend and frontend mean and where the separation occurs. I worry (perhaps without substance) that the definition may vary from port to port. 2) general logistics of actually lopping off huge parts of existing WebKit code and refactoring them in-flight. But I totally think we (you) are up to the challenge :) :DG On Tue, Apr 28, 2009 at 5:05 PM, Jeremy Orlow jor...@chromium.org wrote: Yes, yes, I know this is a horrible idea, but please hear me out :-) Last week, a couple of us (Darin F, Michael N, Jeremy M, and I) had lunch at Apple to talk to talk about sharing more code. HTML 5 brings with it a lot of APIs that reach outside of the top level browsing context boundary (i.e. the render process boundary in Chromium). We talked specifically about localStorage and appCache. Although I believe the following generalizes well for any such API, I recognize that there are some unique constraints for stuff like databases...so I'm not even going to talk about them right now. Anyhow... For a while now, I've looked at a bunch of ways to make localStorage multi-process aware, but really none of them have any hope except one: splitting localStorage into a frontend and backend. The frontend would be the portion in each renderer process that connects into the JS bindings. A single backend would store all the data and be shared by the frontends. Originally, my plan was to do this split and then write my own back end in the browser process, but there are several problems with this. 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. Assuming the only viable solution is having several frontends talking to one backend (I'm confident this is true) and assuming having our own backend is not viable (this also seems true), then the only choice is for us to use the WebCore backend. We can't run this in any renderer process since the response times for browser-renderer communication are unbounded. So that leaves either the browser process or some browser helper process. Creating a helper process for the browser seems like a pretty interesting idea to me since there's already a lot of somewhat dangerous stuff running in the browser process. (The only thing I can remember right now is v8 for parsing .pac files, but I know there's more.) Basically, the helper process would be a sandboxed process where anything dangerous but not bound to a single renderer process would run. Ideally it would store little to no state so that the browser could easily restart it and resend any pending messages if it crashed. For localStorage, the backend (which is part of WebCore) would run there and all localStorage messages would be proxied through the browser process. The VFS could be used to retrieve file handles. The other option is to simply run part of WebCore's localStorage within the browser process. LocalStorage only depends on WTF, so this really isn't _that_ terrible of an idea. Thoughts? Anyhow, the WebKit guys we talked to like the idea of a split frontend/backend, especially if it means we'll continue sharing code. I believe Michael is going to be doing something similar for AppCache. 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: Some help with Layout Test regressions
There's a change to DOMWindow.idl, which pretty much always warrants a clobber on Win builds. I just clobbered WebKit builder, let's see what happens. :DG On Wed, Apr 29, 2009 at 4:11 PM, Jeremy Moskovich jer...@chromium.org wrote: Hi, Today's WebKit merge (42932:42994 - http://trac.webkit.org/changeset?new=42...@trunkold=42...@trunk) has brought in some new regressions. If anyone has any spare cycles I'd really appreciate it if you might be able to look at these - http://crbug.com/11178: xss stuff: LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-addEventListener.html LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-shortcut.html LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-addEventListener.html LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-shortcut.html LayoutTests/http/tests/security/listener/xss-window-onclick-addEventListener.html LayoutTests/http/tests/security/listener/xss-window-onclick-shortcut.html chrome/http/tests/security/listener/xss-inactive-closure.html LayoutTests/http/tests/security/xss-eval.html and: DEBUG WIN : LayoutTests/transitions/repeated-firing-background-color.html = FAIL MAC : LayoutTests/fast/dom/Document/open-with-pending-load.html = CRASH Thanks, Jeremy --~--~-~--~~~---~--~~ 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: Tree is closed - v8 bustage.
It looks like the missing dependency did the trick: both clobber of Chromium builder and clean local build work now. Can haz open tree? :DG On Tue, Apr 28, 2009 at 9:04 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Testing the fix ... :DG On Tue, Apr 28, 2009 at 8:36 PM, Bradley Nelson bradnel...@google.com wrote: Looking into a fix, this may be a missing dependency from v8_snapshot on js2c. It would non-deterministically pass with incredibuild. -BradN On Tue, Apr 28, 2009 at 8:32 PM, Feng Qian f...@chromium.org wrote: libraries.cc is a generated file, did you try a clean build? On Tue, Apr 28, 2009 at 7:56 PM, Ben Goodger (Google) b...@chromium.org wrote: The tree is closed. Several people are seeing the following error when compiling on Windows: Error 1 fatal error C1083: Cannot open source file: '..\..\..\chrome\Debug\obj\global_intermediate\libraries.cc': No such file or directory c1xx Error 2 fatal error LNK1181: cannot open input file '..\..\..\chrome\debug\lib\v8_nosnapshot.lib' mksnapshot Error 3 Error result 127 returned from 'C:\Windows\SysWow64\cmd.exe'. Project It is not clear to me when this started happening. It seems to have shown up mysteriously for a while on the XP release buildbot at r14784 but then mysteriously disappeared again at 14787. Reverting various changes around this range does not help. The tree should not be reopened until this is resolved. -Ben --~--~-~--~~~---~--~~ 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: src/WEBKIT_MERGE_REVISION
Please don't kill it just yet. Let me switch the Merge Tracker to use DEPS and then we can kill it. :DG On Mon, Mar 23, 2009 at 10:03 PM, Eric Seidel esei...@chromium.org wrote: Kill it (or I can, as part of the merge tomorrow)... so long as the merge instructions are up to date. On Mon, Mar 23, 2009 at 5:46 PM, Ojan Vafai o...@google.com wrote: I think this file is basically useless at this point. All the information in it is encoding in src/DEPS (it now has a webkit_revision VAR). Any objection to getting rid of this file? It's one fewer thing for the merger to keep track of. I'll delete the file tomorrow if I hear no objections. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: src/WEBKIT_MERGE_REVISION
My merge tracker still uses it. I can rewrite to switch over to DEPS, though it may not be tomorrow :) :DG On Mon, Mar 23, 2009 at 5:46 PM, Ojan Vafai o...@google.com wrote: I think this file is basically useless at this point. All the information in it is encoding in src/DEPS (it now has a webkit_revision VAR). Any objection to getting rid of this file? It's one fewer thing for the merger to keep track of. I'll delete the file tomorrow if I hear no objections. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mergers: ignore InspectorController changes for a little while.
If you don't do the merges, you can stop reading now -- though you might ask yourself why you're not doing the merges. They are so much fun. In the next few days (hopefully not weeks), I am making changes to InspectorController in an effort to unfork it. This is the good news. The bad news is that there's a certain transition period, during which merging InspectorController will seem a little bit ... difficult. So, to make your merging work easier, here are the instructions: * Don't accept any changes from upstream to InspectorController.(cpp|h|idl). See? Easy! :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: Let's make build system history!
Mark rocks! Send him your money. :DG On Sun, Mar 1, 2009 at 5:39 PM, Ben Goodger (Google) b...@chromium.org wrote: Awesome! Thanks for getting this together, Mark. Do you have any idea what the ETA for Linux and Windows is? -Ben On Sun, Mar 1, 2009 at 4:32 PM, Mark Mentovai m...@chromium.org wrote: The GYP-based build is now automatic, mandatory, and totally awesome on the Mac. I just checked in a change to remove our old Xcode projects and have GYP generate project files for you every time you gclient sync. If you participated in the test on Friday, please remove the hooks section from your .gclient file. Project file generation is now automatic on all Macs via a hook in the DEPS file. In order to maintain the Mac build now, you must edit the .gyp files checked in throughout the tree. Some of you have been doing this already (thanks!) and all of the feedback I've received with respect to .gyp file maintenance has been very positive. Additional documentation will be coming soon. In the mean time, you no longer need to Cc me on reviews involving trivial changes to .gyp files (such as adding or removing files), although I will keep up with changes to those files after they've been committed for at least the next week. If you have more complicated .gyp file changes to make, or you just want peace of mind, please do send the review to me. When you make a change to a .gyp file locally and want to regenerate new Xcode projects, you can use gclient runhooks --force. This is a new command that will cause the GYP hook in the DEPS file to run. Please use this instead of invoking GYP directly as I had previously advised. If you have made any local modifications to the old set of Xcode projects, just revert them. 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: Fix inspector load. This method is called on InspectorController...
I actually didn't mean to start this conversation. Is there still time to run away and hide? :) On a (slightly) more serious note, I agree with your assessment and I thought at first that there was some work being done on that. :DG On Fri, Feb 20, 2009 at 12:25 PM, Ojan Vafai o...@chromium.org wrote: -chromium-reviews, +chromium-dev Not really sure. It seems to me that we need to send patches upstream to make InspectorController not depend directly on JSC. It doesn't seem like it should need to interact so directly with JSC. It's a non-trivial amount of work. Is there another way we could tackle this? Ojan On Fri, Feb 20, 2009 at 12:21 PM, dglaz...@chromium.org wrote: LGTM. BTW, what's our plan on getting this file unforked? :) http://codereview.chromium.org/27007 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Merge 41017:41057 also needs a clobber for Windows folks
Hi All, Because the latest merge introduces a change to third_party/WebKit/WebCore/css/html4.css, which is only picked up by DerivedSources.make, making that change actually appear in your build requires a clobber. :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: Merge 41017:41057 also needs a clobber for Windows folks
As it turns out, the clobber applies to Mac and possibly Linux builds. Basically, clobber all. :DG On Wed, Feb 18, 2009 at 3:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Hi All, Because the latest merge introduces a change to third_party/WebKit/WebCore/css/html4.css, which is only picked up by DerivedSources.make, making that change actually appear in your build requires a clobber. :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] Windows builds will need a clobber for rev 9859
Hi All, Because the latest merge brought down a change to CSSNames.in (http://trac.webkit.org/changeset/40939), all those of us building on Windows will need to clobber: delete your build directory and start with a clean build. :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: 2-day merges and the cleanup schedule
Generally +1, except I just imagined the situation where the merger collides with the fixer. So maybe no overlapping, just do the merge every other day? :DG On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson bre...@chromium.org wrote: On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene p...@chromium.org 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. 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. 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. 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
This is veering wildly off-topic, but I think the key to solving merge regressions is in moving to an integration model. With the integration model, we can integrate one WebKit changeset at a time, and clearly identify the regressions. This would go a long way in identifying the cause and addressing the issue. Unfortunately, currently we have engineers fixing layout tests and making changes to our WebKit fork, which makes integration model ... complicated. What if we go with an integration-merge model, which works as follows: 1) we have a separate WebKit git repository (hosted on someone's machine even), which has a branch with all of our changes applied as one (or more) patch. 2) you pull WebKit changes, rebase (in other words, re-apply our change patches), see if the changes broke anything. 3) if they did, identify the changeset that breaks stuff by using git bisect (nifty stuff, I might say), then mark it in text_fixable and file a bug 4) merge integrated changes into main svn repository. ... or something like that? Somebody take this idea and flesh it out to make it excellent! :) :DG On Thu, Jan 15, 2009 at 2:51 PM, Scott Violet s...@chromium.org wrote: I definitely get that a merge is no trivial amount of work, and my expectations are probably unrealistic without more than one person working on a merge at a time. I was hoping for a magic bullet, but those are only in movies:( -Scott 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 p...@chromium.org wrote: On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson bre...@chromium.org wrote: On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene p...@chromium.org 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] The Process Question: How do we change WebKit code?
Dear People of Chromium, I've been thinking about the process of making changes to WebKit code in a logical and consistent fashion (note, that doesn't necessarily preclude sane). Until we've switched to the integration model, we are still in a vendor branch state and thus the process of tweaking WebKit code is not what you call a that-was-easy effort. Nevertheless, we must have a somewhat trivialized way of doing it. Here's what I've come up so far: A. If the change is to common code (WebCore proper, JavaScriptCore/wtf), make it upstream -- it will be picked up by our daily merges. B. If the change is to our port (platform/graphics/skia|chromium, etc.), you can do the following: 1) make the change downstream and make sure it doesn't break anything 2) submit the change upstream and get it reviewed/committed 3) reconcile any deltas that may have occurred during review process -- the merge custodian will thank you. The basic difference is making sure that the changes to our port work before they go upstream. It would certainly be more frustrating to wait for the daily merge to pick up your tweaks and find out that they were wrong. However, let's try to avoid situations where the change is stuck in WebKit review limbo or abandoned, leaving forked files in our vendor branch. I am not sure whether we need any special rules for these, aside from the occasional stark glare from the merge people. What do you think? Good rules, bad rules? Comments? Questions? Quirky and entertaining remarks? :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: The Process Question: How do we change WebKit code?
http://sites.google.com/a/chromium.org/dev/developers/webkit-changes :DG On Fri, Jan 9, 2009 at 11:15 AM, Dimitri Glazkov dglaz...@google.com wrote: Dear People of Chromium, I've been thinking about the process of making changes to WebKit code in a logical and consistent fashion (note, that doesn't necessarily preclude sane). Until we've switched to the integration model, we are still in a vendor branch state and thus the process of tweaking WebKit code is not what you call a that-was-easy effort. Nevertheless, we must have a somewhat trivialized way of doing it. Here's what I've come up so far: A. If the change is to common code (WebCore proper, JavaScriptCore/wtf), make it upstream -- it will be picked up by our daily merges. B. If the change is to our port (platform/graphics/skia|chromium, etc.), you can do the following: 1) make the change downstream and make sure it doesn't break anything 2) submit the change upstream and get it reviewed/committed 3) reconcile any deltas that may have occurred during review process -- the merge custodian will thank you. The basic difference is making sure that the changes to our port work before they go upstream. It would certainly be more frustrating to wait for the daily merge to pick up your tweaks and find out that they were wrong. However, let's try to avoid situations where the change is stuck in WebKit review limbo or abandoned, leaving forked files in our vendor branch. I am not sure whether we need any special rules for these, aside from the occasional stark glare from the merge people. What do you think? Good rules, bad rules? Comments? Questions? Quirky and entertaining remarks? :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/port is moving into third_party/WebKit/WebCore
As of Christmas Eve, we have:
webkit/port/bindings/{scripts,v8}
webkit/port/platform/image-decoders
webkit/port/platform/graphics/mac
webkit/port/DerivedSources.make
Merry Christmas and/or Festivus, everyone!
Oh, and I broke the build yesterday, and eroman fixed it. He da man.
:DG
On Tue, Dec 23, 2008 at 3:48 PM, Darin Fisher da...@chromium.org wrote:
For now, just operate the same as you would had these files still resided in
webkit/port. Just don't forget to roll DEPS :)
We'll eventually be updating the merge tracker
(http://build.chromium.org/merge) to indicate the set of files and diffs
that have yet to be upstreamed.
-Darin
On Tue, Dec 23, 2008 at 2:51 PM, Adam Barth aba...@chromium.org wrote:
I see. Can I make changes to them in third_party, or should I wait
for them to appear upstream?
Adam
On Tue, Dec 23, 2008 at 1:35 PM, Dimitri Glazkov dglaz...@google.com
wrote:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/
These haven't been yet upstreamed. We just started by moving them into
our vendor branch.
:DG
On Tue, Dec 23, 2008 at 1:31 PM, Adam Barth aba...@chromium.org wrote:
I'm confused. I need to fix a bug in ImageSourceSkia.cpp, but I can't
find it
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/graphics/
or
http://trac.webkit.org/browser/trunk/WebCore/platform/graphics
Where did it go?
Adam
On Mon, Dec 22, 2008 at 8:42 PM, Darin Fisher da...@chromium.org
wrote:
OK, much of webkit/port now lives in third_party/WebKit.
All that remains is:
webkit/port/bindings/{scripts,v8}
webkit/port/bridge/chromium
webkit/port/page/chromium
webkit/port/page/inspector
webkit/port/platform/image-decoders
webkit/port/platform/mac
webkit/port/platform/graphics/mac
webkit/port/DerivedSources.make
We should be able to finish moving most of the rest of these files
tomorrow.
-Darin
On Mon, Dec 22, 2008 at 11:48 AM, Mohamed Mansour
m0.interact...@gmail.com
wrote:
I guess I will stop till your done!
On Mon, Dec 22, 2008 at 2:42 PM, Darin Fisher da...@chromium.org
wrote:
FYI
Please expect conflicts if you are trying to make changes to
webkit/port.
-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/port is moving into third_party/WebKit/WebCore
We haven't started upstreaming yet, so I'd say until some time, you
can work on them directly.
This of course will change when the upstreaming starts.
:DG
On Tue, Dec 23, 2008 at 2:51 PM, Adam Barth aba...@chromium.org wrote:
I see. Can I make changes to them in third_party, or should I wait
for them to appear upstream?
Adam
On Tue, Dec 23, 2008 at 1:35 PM, Dimitri Glazkov dglaz...@google.com wrote:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/
These haven't been yet upstreamed. We just started by moving them into
our vendor branch.
:DG
On Tue, Dec 23, 2008 at 1:31 PM, Adam Barth aba...@chromium.org wrote:
I'm confused. I need to fix a bug in ImageSourceSkia.cpp, but I can't find
it
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/graphics/
or
http://trac.webkit.org/browser/trunk/WebCore/platform/graphics
Where did it go?
Adam
On Mon, Dec 22, 2008 at 8:42 PM, Darin Fisher da...@chromium.org wrote:
OK, much of webkit/port now lives in third_party/WebKit.
All that remains is:
webkit/port/bindings/{scripts,v8}
webkit/port/bridge/chromium
webkit/port/page/chromium
webkit/port/page/inspector
webkit/port/platform/image-decoders
webkit/port/platform/mac
webkit/port/platform/graphics/mac
webkit/port/DerivedSources.make
We should be able to finish moving most of the rest of these files
tomorrow.
-Darin
On Mon, Dec 22, 2008 at 11:48 AM, Mohamed Mansour
m0.interact...@gmail.com
wrote:
I guess I will stop till your done!
On Mon, Dec 22, 2008 at 2:42 PM, Darin Fisher da...@chromium.org wrote:
FYI
Please expect conflicts if you are trying to make changes to webkit/port.
-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: Consolidating our platform-specific layout test results
Pam++! :DG On Thu, Nov 13, 2008 at 6:02 PM, Darin Fisher [EMAIL PROTECTED] wrote: Thanks for cleaning this up, Pam!!! On Thu, Nov 13, 2008 at 4:57 PM, Pam Greene [EMAIL PROTECTED] wrote: Today I got our custom (platform-specific) layout test results mostly straightened out. (Apologies for the large-ish sync that will cause.) If you re-baseline tests, please keep reading. We no longer keep kjs or common results. The layout_test_results directory will be gone within the hour. All platform baselines, whether they're text, images, or checksums, are now in webkit/layout_tests/platform/chromium-win/. (We can create chromium-mac/ and others as needed.) Eventually I, or someone else, will adjust run_webkit_tests.py so its --new-baseline option puts files into the platform-specific directory by default, but for now, please remember to specify the new path. - Pam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[chromium-dev] Fwd: [chromium-dev] started next webkit merge (to r38097)
Unbelievable ... chromium-dev just ate it. :DG -- Forwarded message -- From: Dimitri Glazkov [EMAIL PROTECTED] Date: Tue, Nov 4, 2008 at 4:02 PM Subject: Re: [chromium-dev] started next webkit merge (to r38097) To: chromium-dev@googlegroups.com The Win merge is now building and even passing some tests. Can Mac/Linux folks chip in and help out getting their bots green? And by help out, I mean actually doing it, cuz I ain't no Mac or Linux expert :) :DG On Tue, Nov 4, 2008 at 12:49 PM, Darin Fisher [EMAIL PROTECTED] wrote: FYI, we have started the next webkit merge to r38097. Please minimize your changes to third_party/WebKit. Unlike last time, you do not need to apply your changes to the third_party/WebKit on the merge branch. We'll take care of that, but please please please try not to make many changes to third_party/WebKit ;-) -Darin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: webkit unforking
To me, it looks like the case where we could create an abstraction, similar to what I did with ExceptionContext, which encapsulates ExecState* and ArgList* on JSC side and provides a way to pass strings/line numbers for V8. So, at this point I would merge Console.cpp into one two-chunked file (option 1) with the plan to implement and upstream ConsoleContext. ... Perhaps ExceptionContext ConsoleContext = ScriptContext? :DG On Tue, Oct 7, 2008 at 2:27 PM, Elliot Glaysher [EMAIL PROTECTED] wrote: As the person who threw together a good chunk of Console.cpp, I'd prefer that we keep Console.cpp local, at least in the short term because it's nowhere near complete yet. I'm currently waiting for crbug.com/2960 to be fixed in V8 so Console output has line numbers, which will require me to change the declarations in the USE(V8) section of Console.h so it also takes a line number... -- Elliot On Tue, Oct 7, 2008 at 2:17 PM, Ojan Vafai [EMAIL PROTECTED] wrote: If you are helping with the next merge, or with unforking WebKit code, read on. Otherwise, don't bother. In attempting to get the KJS build compiling I ran into a case that seems similar to many of the issues we've run into that required us to move things into port. I figured we could talk now about what the right solution is both so I can fix the error in front of me and so we'll have a good sense of how to move forward on these issues. In Console.h, most of the methods take KJS specific types and we fork them to take Strings, e.g. #if USE(JSC) void debug(KJS::ExecState*, const KJS::ArgList); #elif USE(V8) void debug(const String message); #endif Then we have our own implementation of Console.cpp that implements just the V8 methods and is a totally different implementation than the KJS equivalents. I see a couple solutions: 1. Move our V8 implementation of Console.cpp methods into the third_party/WebKit one wrapped in #if USE(V8). 2. Move Console.cpp out of port.vcproj and into V8Bindings.vcproj and KJSBindings.vcproj appropriatly. Are there other options? Preferences? Ojan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: [chromium-reviews] Re: First batch of The Big Unforking
-chromium-reviews +chromium-dev I am testing a simplistic setup with using svn properties to track WebKit versions, and it seems to work pretty well and avoids having to do the extra scrub/commit steps. I am writing this up, will post soon. :DG On Fri, Oct 3, 2008 at 2:00 PM, Darin Fisher [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 1:50 PM, Mark Mentovai [EMAIL PROTECTED] wrote: Darin Fisher wrote: Given the current approach, how do I compute a diff that contains just our changes? Can we tag virgin WebKit imports for ease of diffing? That would be great. I think that one way to do that is to have a revision number for all of the files under third_party/WebKit that corresponds to an exact copy of what lives upstream. Then, we do another CL that layers our changes on top of that. This process would be repeated each time we merge so that we always have a clean way to generate a diff and svn log will show the deltas being re-applied. The downside is that we lose track of why a delta was applied. Merge process looks like: For each modified file, compute diff, overwrite file with the new virgin file. Commit. Now, re-apply the diff. Commit. Does that sound right? -Darin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
