Once we have this sort of tool for webkit.org then those of us who
work on webkit.org could just add the new baselines when we commit the
patches in the first place. :)
On Fri, Jan 8, 2010 at 5:38 PM, Julie Parent jpar...@chromium.org wrote:
Yeah, me too.
This is what tends to lead to me
I expect that WebKit folks would be willing to help flight WebKit test
flakyness once we move more of our testing infrastructure into the
svn.webkit.org repository.
You might make a similar plea for help on webkit-dev, although I doubt
you'll get a super-positive response until webkit folks can
http://build.chromium.org/buildbot/waterfall/stats
On Tue, Dec 8, 2009 at 2:51 PM, Dan Kegel d...@kegel.com wrote:
Hey folks,
I seem to recall we have a dashboard somewhere showing
the cycle time of each of our build/test bots, but I can't
find it. Can somebody point me to it?
If it
That's about the awesomest thing ever. I want this in my build.webkit.org!
-eric
On Fri, Nov 20, 2009 at 1:58 PM, Ojan Vafai o...@chromium.org wrote:
As of yesterday, we now retry any unexpected webkit failures. If they pass
the second time around, then we turn the bot orange and list the
track total binary size here:
http://build.chromium.org/buildbot/perf/dashboard/sizes.html
I don't know of any place we track per-module sizes.
On Fri, Nov 13, 2009 at 2:33 PM, Eric Seidel esei...@chromium.org wrote:
Do we have any hard data about where our binary size goes? It seems
Do we have any hard data about where our binary size goes? It seems
such data would be very useful.
On Fri, Nov 13, 2009 at 2:14 PM, Evan Martin e...@chromium.org wrote:
I measured that SVG is nearly a sixth of the binary size of a Chrome
debug build. That's not only more compile time, it's
Looks like this is the WebKit bug URL:
https://bugs.webkit.org/show_bug.cgi?id=21955
On Thu, Nov 12, 2009 at 9:41 AM, Ojan Vafai o...@google.com wrote:
This is a long-standing WebKit bug. The current behavior is correct for Mac.
Linux/Win should behave as you expect. Patches welcome. :)
On
ReportCrash is crawling for stacks and looking up symbol names. If
your process is a debug build it has huge symbol tables.
I don't know of any way to disable ReportCrash. However, you can add
some code to your process to catch the offending symbols and exit
instead.
You can also run the
Interesting. WebKit has similar functionality as:
bugzilla-tool rollout 12345
We've found that git reverts are at least an order of magnitude faster
than SVN reverse merges.
I wonder what bugzilla-tool/drover can learn from one another.
-eric
On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain
Thankfully I'm telelegetic and can read it from here. Looks amazing.
Ping me once it's up and I'll give it the ol' r+.
-eric
On Wed, Oct 28, 2009 at 5:51 PM, Adam Langley a...@chromium.org wrote:
On Wed, Oct 28, 2009 at 5:47 PM, Evan Stade est...@chromium.org wrote:
One could show baselines of all the other platforms instead of just an
upstream baseline.
I'm not really sure from the output what this tool does. So it's
difficult for me to tell how useful it would be to upstream.
-eric
On Thu, Oct 15, 2009 at 8:38 PM, Glenn Wilson gwil...@chromium.org
In case any of you who hack on WebKit aren't on webkit-dev. (If
that's you, you should definitely join webkit-dev now. It's very very
low traffic and very high signal to noise ratio.)
-eric
-- Forwarded message --
From: Brian Weinstein bweinst...@apple.com
Date: Thu, Oct 15,
YAY! :) Begone ye setTimeout!
setTimeout is also lame because it makes the tests run slower.
-eric
On Fri, Oct 9, 2009 at 9:52 PM, Julie Parent jpar...@chromium.org wrote:
For those of you looking into flaky tests -
I've found a surprising number of tests that are flaky because they use a
Who knew?
Looks like Mark (Rowe) recently updated their buildbot:
http://build.webkit.org/console
Very hot.
There is no link to it anywhere that I can see.
-eric
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View
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
WebKit has talked about try servers for a very long time. But none
have been made.
https://bugs.webkit.org/show_bug.cgi?id=29062
is the most recent discussion about this that I remember.
Mark Rowe mr...@apple runs build.webkit.org to my knowledge.
-eric
On Tue, Sep 29, 2009 at 3:50 PM,
I'm not sure I understand what you're saying. I assume you're aware
that script phases in XCode list explicit dependencies.
I think I'd have an easier time parsing your paragraph with specific examples.
-eric
On Tue, Sep 22, 2009 at 5:30 AM, Thomas Van Lenten
thoma...@chromium.org wrote:
No comment on 1.4 compatibility goals. :)
I would bet most developers would want to upgrade to 1.6 for all the
speed improvements. Official package:
http://www.open.collab.net/downloads/community/
(Which installs it in the strange place of /opt/subversion/bin.)
-eric
On Mon, Sep 21, 2009 at
For my use case: If there is more than one commit on a branch, then
that is intentional history on my part. :) So yes.
-eric
On Fri, Sep 18, 2009 at 11:45 AM, Nico Weber tha...@chromium.org wrote:
BTW, do you typically have useful history on these branches?
Typically the reason to preserve
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
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
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
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
WebKit's is:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/bisect-builds
Maybe there is code to share there? Or with a fancier python one from
Chromium we can replace that old perl thing.
-eric
On Thu, Sep 3, 2009 at 6:30 PM, Evan Martin e...@chromium.org wrote:
I feel a couple
That is really slick. gyp-authors++
-eric
On Fri, Aug 14, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote:
If you are like me and accustomed to hacking build/common.gypi to enable
/MP under VS2005, then please read on:
It turns out that there is a better way! Instead, just create a
Never mind, that line is already complete!
GENERATE_BINDINGS_SCRIPTS = \
bindings/scripts/CodeGenerator.pm \
bindings/scripts/IDLParser.pm \
bindings/scripts/IDLStructure.pm \
bindings/scripts/generate-bindings.pl \
On Tue, Aug 11, 2009 at 7:51 AM, Eric Seidel esei
The fix is awaiting review:https://bugs.webkit.org/show_bug.cgi?id=19161
On Sat, Aug 8, 2009 at 10:37 AM, Adam Barth aba...@chromium.org wrote:
I believe Eric Seidel just fixed this bug. He can tell you more.
Adam
On Sat, Aug 8, 2009 at 10:03 AM, n179911n179...@gmail.com wrote:
Hi
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
On Wed, Jul 22, 2009 at 10:13 AM, Darin Fisherda...@chromium.org wrote:
On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote:
Actually, I've never been too sure about reverting in WebKit: does one
revert the ChangeLog file too or add another ChangeLog entry at the
top
You should know about bugzilla-tool
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/bugzilla-tool
if you plan on doing commits for other people. It will make your life
much easier. :)
bugzilla-tool land-patches BUGNUMBER
is all you need. :) (Assuming the tree is green so that all the
This question comes up every so often on webkit-dev. :)
The response there has been why does one ever want a webkit source
checkout w/o layout tests?
- If you're doing development, you need the layout tests.
- If you're just want to run tip-of-tree, nightly builds are a better
way of doing
I will note that in WebKit's experience Trac is super-slow (at least
the version webkit.org is using). Trac does not seem to do much (if
any) caching.
-eric
On Wed, Jul 1, 2009 at 7:27 PM, Jeremy Orlowjor...@chromium.org wrote:
Is there any reason we use ViewVC rather than something like trac
It seems to be a common misconception of Google engineers joining
WebKit that WebKit expects design docs like Google does.
I see Google writing design docs a lot. I saw one or two in my 3
years at Apple. I've never seen WebKit use them.
Google engineers posted 3 design docs to webkit-dev last
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
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
I think such a build would be useful for performance testing of the
rest of our infrastructure. It also makes having a webkit.org
chromium-webkit build easier. I'm not sure how hard maintaining such
a build would be with the new gyp goodness.
-eric
On Thu, Jun 11, 2009 at 4:06 PM, Dimitri
FYI, WebKit also has a script which bisects over binaries (nightly builds):
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/bisect-builds
Perhaps long term there is some code to share there (like maybe we can
replace their perl script with our python script). ;)
-eric
On Fri, Jun 5,
I think this would be out of scope for WebKit. Probably would fall
under non-goals:
http://webkit.org/projects/goals.html
That said, I be this already works with the Apple WebKit Windows
build. If you build WebKit with CG support on Windows then you likely
already have this support from CG. :)
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
FYI, due to:
http://trac.webkit.org/changeset/41907
I intend to turn off ENABLE_VIDEO for Chrome until the video folks have a
chance to make it work with the re-write we're picking up as part of this
merge.
I've spoken to hclam and fishd and we believe this will not break any tests
(since video
I'm trying to build Chrome this morning and v8_mksnapshot.exe is crashing?
This is a clean build.
Thoughts?
-eric
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
++
v8_mksnapshot.exe!__tmainCRTStartup() Line 327 + 0x12 bytesC
kernel32.dll!7c816fd7()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
On Fri, Feb 20, 2009 at 11:54 AM, Eric Seidel esei...@chromium.org wrote:
I'm trying to build
The quickest way to get your patches approved, is to submit enough
that we can offer you commit access. :)
-eric
On Tue, Dec 16, 2008 at 2:44 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Dec 16, 2008 at 1:52 PM, Darin Fisher da...@chromium.org wrote:
http://nightly.webkit.org/start has a
That is s awesome Evan.
On Tue, Oct 28, 2008 at 11:11 AM, Evan Martin [EMAIL PROTECTED] wrote:
If you're using git-cl, it now can check whether the tree is closed
automatically. (Thanks Tony!)
1) Pull a new git-cl.
2) Run git cl config again. It'll ask you for a tree status URL --
If you're hacking on WebKit and don't feel like you fully understand
RefPtr/PassRefPtr, you should read this:
http://webkit.org/coding/RefPtr.html
Darin (Adler) just updated it last night. I think it's a useful intro
into ref-counting in WebCore.
-eric
There are a bajillion logs of #webkit. None of them official.
-eric
On Tue, Oct 7, 2008 at 2:50 PM, Evan Martin [EMAIL PROTECTED] wrote:
Eric asked on #webkit, and (since I don't think they log(?)) I'll just
paraphrase a response from there, which is that this is a bad idea
since the
Greenblatt
[EMAIL PROTECTED] wrote:
Hi Eric,
Is there a document somewhere that describes the changes that we can expect?
Regards,
Marshall
On Mon, Sep 29, 2008 at 6:00 PM, Eric Seidel [EMAIL PROTECTED] wrote:
We plan to land the webkit_merge_branch onto trunk tomorrow afternoon.
http
http://bugs.webkit.org/ is the place to file WebKit-level issues. (Issues
which reproduce in both Safari and Chrome).
http://webkit.org/quality/reporting.html
There are numerous known issues with WebKit's object tag handling:
We no longer compile with PLATFORM(CAIRO) on the merge branch. Thus I
expect that can be removed.
-eric
On Thu, Sep 18, 2008 at 4:13 PM, Evan Martin [EMAIL PROTECTED] wrote:
I'm playing with building a no-op test_shell that links in GTK.
The GTK header stack pulls in
49 matches
Mail list logo
