[chromium-dev] Re: Mac Chrome launch speed = the awesome
I wish I had an intel mac now, but alas that's pretty damned impressive for an application with a native cocoa UI. It's good to see the Linux and Mac ports getting the attention they deserve as late. So I guess I'll take this time to throw in my congratulations to you chrome guys too On Mon, Sep 7, 2009 at 11:11 PM, Adam Barth aba...@chromium.org wrote: Dear Mac folks: Thanks for making Mac Chrome launch ridiculously fast. I really enjoy that, on my laptop, the main window is painted before the dock icon has even crested its first bounce. Adam -- Stefan Nuxoll ste...@nuxoll.eu.org --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Spike in Linux Reference times on Perf tests
A few of the perf runs for linux shows a sudden change in the reference build performance. These show a slow down: Page Cycler Intl2 Page Cycler DHTML These show a speed up/improvement: Page Cycler Moz Page Cycler Intl1 Startup SunSpider V8 Benchmark Page Cycler Morejs The other odd part is the run before these runs show's agl's checkin to move and maybe update the reference builds? So why it took a cycle to show up I'm not sure. TVL --~--~-~--~~~---~--~~ 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: Why scrollbars don't match on the Mac pixel tests
Interesting, and surprising. Have you spoken to the #webkit folks about this? Hyatt was the one that did all this re-factoring, maybe this is expected, or not. I'd drop him an email directly if you can't get anything out of #webkit. On Fri, Sep 4, 2009 at 5:17 PM, Avi Drissmana...@google.com wrote: Speculation here (while I'm not 100% convinced I'm 99.44% there), but... Scrollbar thumb size has always been fuzzy. On the original Mac there was no way to specify the thumb size, and even today HIThemeDrawTrack (which is the most modern Mac theme-drawing API) has a parameter |viewsize| which is under-specified. While the theory is to make thumb : track :: view : doc size the Mac scrollbar code passes in the page scroll size for the viewsize parameter. You can see the code in ScrollbarThemeMac for details, but as an example, for LayoutTests/css1/basic/inheritance.html, the WebCore Scrollbar that had values visible size = 600, total size = 724 turned into: scrollbar size: 15x585 (we lose 15px to the growbox) min: 0 max: 124 viewsize: 560 (visible size of 600 - cAmountToKeepWhenPaging; see ScrollView::updateScrollbars) Now the scrollbar isn't 560/585 (96%) of the track so it's not clear where the thumb size (as drawn) is coming from. But that's not the problem. The problem is that I was trying to track down the same numbers for the reference images so I could see where the metrics were diverging. And I couldn't. I got DumpRenderTree from WebCore loading in GDB, but breakpoints in ScrollbarThemeMac.mm wouldn't hit. Nor would breakpoints in Scrollbar.cpp or ScrollView.cpp. In desperation I breakpointed on HIThemeDrawTrack. And that didn't hit either. What did hit was -[NSScroller drawRect:] at this damning backtrace: #0 0x96143759 in -[NSScroller drawRect:] #1 0x9605fbf8 in -[NSView _drawRect:clip:] #2 0x9605e6ef in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #3 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #4 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #5 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #6 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #7 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #8 0x9605d045 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #9 0x96145385 in -[NSNextStepFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #10 0x960594ab in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] #11 0x95f99e7b in -[NSView displayIfNeeded] #12 0x00011ab4 in -[FrameLoadDelegate webView:didFinishLoadForFrame:] at FrameLoadDelegate.mm:207 That's why the scrollbars are different. I thought that they'd moved from using the Cocoa scroll code in WebCore, but it doesn't seem so. Options: 1. Tweak ScrollbarThemeMac to generate values that make HIThemeDrawTrack draw identically to Cocoa (or fork it; same diff) 2. Rebaseline all images that only involve scrollbar diffs without mercy. Avi -- 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: Mac Chrome launch speed = the awesome
And on behalf of many of the other Mac folks, I have to thank Mark for tearing into the problem and doing a lot of detective and coding work to make it happen. He's incredible, and that's why we keep him working on infrastructure work rather than actual Chromium coding; we don't want to embarrass the other platforms by moving Chromium on the Mac too quickly. :) Avi On Tue, Sep 8, 2009 at 10:26 AM, Mark Mentovai m...@chromium.org wrote: On behalf of the Mac folks, you're quite welcome! Mark Adam Barth wrote: Thanks for making Mac Chrome launch ridiculously fast. I really enjoy that, on my laptop, the main window is painted before the dock icon has even crested its first bounce. --~--~-~--~~~---~--~~ 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: Mac Chrome launch speed = the awesome
On behalf of the Mac folks, you're quite welcome! Mark Adam Barth wrote: Thanks for making Mac Chrome launch ridiculously fast. I really enjoy that, on my laptop, the main window is painted before the dock icon has even crested its first bounce. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] runtime flags
It seems there is some confusion with how Chromium handles command line flags/runtime settings. Could someone who actually knows please post to webkit-dev to explain? https://bugs.webkit.org/show_bug.cgi?id=28941 https://bugs.webkit.org/show_bug.cgi?id=28930 I gave my attempt at an explanation in https://bugs.webkit.org/show_bug.cgi?id=28941#c5. -eric --~--~-~--~~~---~--~~ 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: Why scrollbars don't match on the Mac pixel tests
OK, here's a more interesting backtrace (bp on -[NSScroller setKnobProportion:]: #00x960957e1 in -[NSScroller setKnobProportion:] #10x95fb0de3 in -[NSScrollView reflectScrolledClipView:] #20x009a4aef in -[WebDynamicScrollBarsView(WebInternal) reflectScrolledClipView:] at WebDynamicScrollBarsView.mm:211 #30x9607ef3a in -[NSClipView _reflectDocumentViewFrameChange] #40x95f7a83d in -[NSView _postFrameChangeNotification] #50x95f806e7 in -[NSView setFrameSize:] #60x95f7693e in -[NSControl setFrameSize:] #70x040d2e2c in WebCore::ScrollView::platformSetContentsSize at ScrollViewMac.mm:136 #80x040cfae7 in WebCore::ScrollView::setContentsSize at ScrollView.cpp:229 #90x03bc41a4 in WebCore::FrameView::setContentsSize at FrameView.cpp:356 #100x03bc244e in WebCore::FrameView::adjustViewSize at FrameView.cpp:376 #110x03bc63b5 in WebCore::FrameView::layout at FrameView.cpp:651 What happens is that in ScrollView::setContentsSize they take the platformWidget() branch (see ScrollView.cpp:229). That lands them in ScrollViewMac.mm and they get Cocoa all the way down. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux HTML5, List of Libraries
Hello, I'm sorry if this is not the right place for this question bue here I go. Can any of the Linux Version's developers share a list of all the libraries, versions and file names needed for Chromium/Chrome, as dependencies, in Linux 64 bits? Specially those needed for Text rendering (Specially japanese, Korean, Chinese, etc.) and HMLT5 Video and audio tags. I have been trying for a few days now and can't make those characteristics work. Thank you so much in advance. I'm using Archlinux 2009.2 64 Bits edition and I'm familiar with linux development tools, I'm not an expert but I can also help doing specific test under this platform if by any chance needed :D. --~--~-~--~~~---~--~~ 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: Linux HTML5, List of Libraries
On Tue, Sep 8, 2009 at 5:29 AM, Luis Canaval martin.cana...@gmail.comwrote: HMLT5 Video and audio tags Note that only Google Chrome builds ship the decoders for h.264, so if you're using Chromium and trying to test, say, the YouTube HTML5 demo site, it won't work. 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: Linux HTML5, List of Libraries
We use FFmpeg for HTML5 audio/video. I haven't fully tested a 64-bit build of it under Linux yet. If you're interested in building the libraries you can read through the instructions: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.chromium?revision=25428view=markup http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.chromium?revision=25428view=markup Andrew On Tue, Sep 8, 2009 at 10:27 AM, Peter Kasting pkast...@google.com wrote: On Tue, Sep 8, 2009 at 5:29 AM, Luis Canaval martin.cana...@gmail.comwrote: HMLT5 Video and audio tags Note that only Google Chrome builds ship the decoders for h.264, so if you're using Chromium and trying to test, say, the YouTube HTML5 demo site, it won't work. 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: Spike in Linux Reference times on Perf tests
On Tue, Sep 8, 2009 at 5:35 AM, Thomas Van Lententhoma...@chromium.org wrote: A few of the perf runs for linux shows a sudden change in the reference build performance. I had to update the reference builds because the IPC protocol changed on Linux. Thus, a change in the reference speeds to match the current tip-of-tree is expected. 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: Linux HTML5, List of Libraries
If http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites doesn't answer your question, please ask it again and/or update that page so it does. :) On Tue, Sep 8, 2009 at 5:29 AM, Luis Canavalmartin.cana...@gmail.com wrote: Hello, I'm sorry if this is not the right place for this question bue here I go. Can any of the Linux Version's developers share a list of all the libraries, versions and file names needed for Chromium/Chrome, as dependencies, in Linux 64 bits? Specially those needed for Text rendering (Specially japanese, Korean, Chinese, etc.) and HMLT5 Video and audio tags. I have been trying for a few days now and can't make those characteristics work. Thank you so much in advance. I'm using Archlinux 2009.2 64 Bits edition and I'm familiar with linux development tools, I'm not an expert but I can also help doing specific test under this platform if by any chance needed :D. --~--~-~--~~~---~--~~ 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: Mac pixel tests: Why rebaselining is the only real option
Avi Drissman wrote: Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa sizes scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a viewsize value related to the physical size of the scrollbar. The precise formula Cocoa uses to turn the view size into its proportion value is unknown and would either have to be coaxed out of Apple or reverse-engineered. But even if you could fix both of these screws, you'd have to deal with... This all sounds reasonable to me. I'd still like to know a little bit more about screw #2 because it seems like something that we should understand a bit better before we decide to establish our own baselines for these tests. I wonder what happens when the viewsize or one of the other parameters is changed by ±15. Maybe Cocoa is accounting for the other scrollbar's presence or absence differently. 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: Linux HTML5, List of Libraries
Chromium is currently 32-bit x86 only ... sounds like we need to update the build instructions for 64-bit. On Tue, Sep 8, 2009 at 11:47 AM, Evan Martine...@chromium.org wrote: If http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites doesn't answer your question, please ask it again and/or update that page so it does. :) On Tue, Sep 8, 2009 at 5:29 AM, Luis Canavalmartin.cana...@gmail.com wrote: Hello, I'm sorry if this is not the right place for this question bue here I go. Can any of the Linux Version's developers share a list of all the libraries, versions and file names needed for Chromium/Chrome, as dependencies, in Linux 64 bits? Specially those needed for Text rendering (Specially japanese, Korean, Chinese, etc.) and HMLT5 Video and audio tags. I have been trying for a few days now and can't make those characteristics work. Thank you so much in advance. I'm using Archlinux 2009.2 64 Bits edition and I'm familiar with linux development tools, I'm not an expert but I can also help doing specific test under this platform if by any chance needed :D. --~--~-~--~~~---~--~~ 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: Mac pixel tests: Why rebaselining is the only real option
On Tue, Sep 8, 2009 at 11:51 AM, Mark Mentovaim...@chromium.org wrote: Avi Drissman wrote: Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa sizes scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a viewsize value related to the physical size of the scrollbar. The precise formula Cocoa uses to turn the view size into its proportion value is unknown and would either have to be coaxed out of Apple or reverse-engineered. But even if you could fix both of these screws, you'd have to deal with... This all sounds reasonable to me. I'd still like to know a little bit more about screw #2 because it seems like something that we should understand a bit better before we decide to establish our own baselines for these tests. I wonder what happens when the viewsize or one of the other parameters is changed by ±15. Maybe Cocoa is accounting for the other scrollbar's presence or absence differently. Not saying you should do the same thing, but getting the font metrics on Linux to match Windows I recall agl and deanm spent a week or two going back and forth with ok, if you add 0.82 * the baseline here it fixes these three fonts but that fourth one is still different. --~--~-~--~~~---~--~~ 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: Mac pixel tests: Why rebaselining is the only real option
Is that metrics for the layout rectangles or the pixels? Avi On Tue, Sep 8, 2009 at 2:57 PM, Evan Martin e...@chromium.org wrote: On Tue, Sep 8, 2009 at 11:51 AM, Mark Mentovaim...@chromium.org wrote: Avi Drissman wrote: Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa sizes scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a viewsize value related to the physical size of the scrollbar. The precise formula Cocoa uses to turn the view size into its proportion value is unknown and would either have to be coaxed out of Apple or reverse-engineered. But even if you could fix both of these screws, you'd have to deal with... This all sounds reasonable to me. I'd still like to know a little bit more about screw #2 because it seems like something that we should understand a bit better before we decide to establish our own baselines for these tests. I wonder what happens when the viewsize or one of the other parameters is changed by ±15. Maybe Cocoa is accounting for the other scrollbar's presence or absence differently. Not saying you should do the same thing, but getting the font metrics on Linux to match Windows I recall agl and deanm spent a week or two going back and forth with ok, if you add 0.82 * the baseline here it fixes these three fonts but that fourth one is still different. --~--~-~--~~~---~--~~ 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: Mac pixel tests: Why rebaselining is the only real option
Rectangles. On Tue, Sep 8, 2009 at 11:59 AM, Avi Drissmana...@google.com wrote: Is that metrics for the layout rectangles or the pixels? Avi On Tue, Sep 8, 2009 at 2:57 PM, Evan Martin e...@chromium.org wrote: On Tue, Sep 8, 2009 at 11:51 AM, Mark Mentovaim...@chromium.org wrote: Avi Drissman wrote: Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa sizes scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a viewsize value related to the physical size of the scrollbar. The precise formula Cocoa uses to turn the view size into its proportion value is unknown and would either have to be coaxed out of Apple or reverse-engineered. But even if you could fix both of these screws, you'd have to deal with... This all sounds reasonable to me. I'd still like to know a little bit more about screw #2 because it seems like something that we should understand a bit better before we decide to establish our own baselines for these tests. I wonder what happens when the viewsize or one of the other parameters is changed by ±15. Maybe Cocoa is accounting for the other scrollbar's presence or absence differently. Not saying you should do the same thing, but getting the font metrics on Linux to match Windows I recall agl and deanm spent a week or two going back and forth with ok, if you add 0.82 * the baseline here it fixes these three fonts but that fourth one is still different. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] using upstream webkit's git repo in chrome
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: Linux HTML5, List of Libraries
I was under the impression that going to 64-bit isn't just a simple switch in build instructions, there were some components (V8, maybe) that weren't x64 compatible. Anyone else want to comment on this? (Oops, hit Reply instead of Reply All, silly gmail) On Tue, Sep 8, 2009 at 12:53 PM, Lei Zhang thes...@chromium.org wrote: Chromium is currently 32-bit x86 only ... sounds like we need to update the build instructions for 64-bit. On Tue, Sep 8, 2009 at 11:47 AM, Evan Martine...@chromium.org wrote: If http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites doesn't answer your question, please ask it again and/or update that page so it does. :) On Tue, Sep 8, 2009 at 5:29 AM, Luis Canavalmartin.cana...@gmail.com wrote: Hello, I'm sorry if this is not the right place for this question bue here I go. Can any of the Linux Version's developers share a list of all the libraries, versions and file names needed for Chromium/Chrome, as dependencies, in Linux 64 bits? Specially those needed for Text rendering (Specially japanese, Korean, Chinese, etc.) and HMLT5 Video and audio tags. I have been trying for a few days now and can't make those characteristics work. Thank you so much in advance. I'm using Archlinux 2009.2 64 Bits edition and I'm familiar with linux development tools, I'm not an expert but I can also help doing specific test under this platform if by any chance needed :D. -- Stefan Nuxoll ste...@nuxoll.eu.org --~--~-~--~~~---~--~~ 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 Chromium Port
Hi all, I'm working on the Webkit Chromium Port, an attempt at upstreaming a chromium-specific build target into the webkit tree. This is a large project that involves many steps (see: http://trac.webkit.org/wiki/Chromium). I plan to do the following: 1. Merge chromium's webkit/config.h.in into webkit's WebKit/WebCore/config.h. These files have been forked in the past, and now should be merged so they can be shared by both the chromium build and the chromium port build processes. 2. Extract the ncpe, wtf and webcore targets out of chromium's webkit/webkit.gyp and upstream them into gyp/gypi files that will be placed in the webkit tree, so they can be shared by both chromium and the chromium port. A side benefit will be that these configuration files will live closer to the source files they control, which will allow easier code management and enable atomic commits. 3. Create a new directory WebKit/WebKit/chromium, which will have the chromium port's .gyp file and a DEPS file with minimal dependencies. A build bot will use gclient to fetch the dependencies and then build the webkit chromium port. Throughout this process, I plan to eliminate unnecessary dependencies, contributing to the effort of making our builds faster. Suggestions, concerns and warnings will be appreciated. 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: WebKit Chromium Port
On Tue, Sep 8, 2009 at 6:43 PM, Jeremy Orlow jor...@chromium.org wrote: We can probably donate man-power, but I doubt they'll want to take any code from us (for whatever reason)...though we could always ask. :-) Who is they here? We are WebKit. At least all of us with @webkit.orgemail addresses. :) I would caution against we/they wording in this instance... Google employed @webkit folks can set up webkit.org servers if we want to. Mark Rowe officially owns the domain (not apple). I'm sure he'd be happy to point addresses at try servers hosted by Google employed WebKit contributers. :) -eric --~--~-~--~~~---~--~~ 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 WebKit.org builder is now live
Yay! As soon as you believe the builder to be stable (give it a couple days), please post a patch to add it to the core builders list: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/modules/buildbot.py#L46 Once it's there, the bugzilla-tool and the commit-queue will not commit patches unless the builder is green. -eric On Tue, Sep 8, 2009 at 8:50 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Dear Chromiumites and friends of the show, We now have a builder upstream that builds Chromium webkit port: http://build.webkit.org/waterfall (look to the very right of the columns). Granted, the road to the actual complete Chromium WebKit port is still long and winding (https://trac.webkit.org/wiki/Chromium), since this builder simply builds the webcore project in the Chromium repository (kudos to nice WebKit folks allowed us to modify their master config to patch in Chromium-specific gclient sync and compile.py commands for us). Nevertheless, it's progress. Now you can watch all things WebKit blow up faster than ever before! :) More entertainment is coming soon to your ... whatever you're reading this on. :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 Chromium Port
Oh, and further information: webkit.org servers are currently all hosted by macosforge.org on Apple's campus last time I checked. William Siegrist aka wms, wsiegr...@apple officially admins them last I checked. Mark Rowe does some too. I see no reason why Google can't host more webkit.org servers if we want to. To get them added to webkit.org's DNS records we would just need to ask on webkit-dev or ask Mark Rowe directly. -eric On Tue, Sep 8, 2009 at 10:47 PM, Eric Seidel esei...@chromium.org wrote: On Tue, Sep 8, 2009 at 10:39 PM, Jeremy Orlow jor...@chromium.org wrote: If it does work, we could definitely let them know it's an option for those who might want to. We'd have to phrase it delicately though. They're generally quite allergic to us even coming _close_ to pushing our infrastructure on them. Google has it's own fair dose of not invented here. :) WebKit has been quite receptive of the recent script additions we've made, including check-webkit-style (originally cpplint.py) which was entirely Google code. The entire commit-queue architecture they're now using was written by Google employed WebKit contributers (myself, Adam Barth and Dave Levin). I don't mean to pick a fight, but I just don't think this should be a we vs. they argument. Google employs 4 WebKit reviewers (myself, Adam Barth, Dimitri Glazkov and Darin Fisher). Reviewers tend to make the decisions in WebKit land. Furthermore, Apple tends to follow the saying code wins, meaning: given two ideas, one of which is coded and the other which is not the coded one wins. :) If a Googler produces functioning WebKit try bots, the WebKit community certainly isn't going to turn them down. I think Google employed WebKit contributers should feel full license to set up try bots integrated with WebKit's buildbot. I think Googlers should also feel welcome to augment/replace parts of WebKit's buildbot architecture with our improved versions from build.webkit.org. -eric --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
