Here are some things that may help;
*#1 svn server overloading when all the slaves bootstrap at the same time*
The only good work around is to keep an internal read-only svn-mirror that
the slaves use instead of the real svn server.
This means that builds must be triggered on the svn-mirror,
You need to use --force on automated testing. We didn't have to clobber any
slave.
M-A
Le 5 décembre 2010 12:57, Adam Barth aba...@webkit.org a écrit :
maruel mentioned something about command-line flags we can pass to
gclient to make it more robust.
Adam
On Sun, Dec 5, 2010 at 9:49 AM,
We found who started the master and shut it down so this has been fixed, I'm
really sorry about the spam and will make changes so nobody can make this
spam again (+ a filter on non chromium/google email addresses).
M-A
Le 4 août 2010 13:17, Darin Adler da...@apple.com a écrit :
I got a large
2010/4/21 Kevin Ollivier kev...@theolliviers.com
Hi Marc-Antoine,
On Apr 18, 2010, at 10:47 AM, Marc-Antoine Ruel wrote:
2010/4/17 Kevin Ollivier kev...@theolliviers.com
Hi Marc-Antoine,
On Apr 17, 2010, at 11:26 AM, Marc-Antoine Ruel wrote:
Like this?
http://trac.webkit.org/browser
2010/4/20 par...@paroga.com
On Tue, 20 Apr 2010 10:53:55 -0700, Peter Kasting pkast...@google.com
wrote:
AIUI, readability isn't the issue, it's the ability for e.g. Visual
Studio
to correctly understand dependencies itself so that incremental builds
from
inside the IDE (which is where
2010/4/17 Kevin Ollivier kev...@theolliviers.com
Hi Marc-Antoine,
On Apr 17, 2010, at 11:26 AM, Marc-Antoine Ruel wrote:
2010/4/17 Kevin Ollivier kev...@theolliviers.com
Hi Maciej,
On Apr 16, 2010, at 3:34 PM, Maciej Stachowiak wrote:
On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann
2010/4/17 Kevin Ollivier kev...@theolliviers.com
Hi Maciej,
On Apr 16, 2010, at 3:34 PM, Maciej Stachowiak wrote:
On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote:
Am 16.04.2010 um 16:44 schrieb Adam Treat:
I am very skeptical that it is feasible to write a gyp generator
Please guys,
No need to speculate here on what I proposed at the session since Evan
somehow left some details out and let me reinforce some points. For those
who missed the session, please understand that what's Peter said isn't
exactly what we agreed on.
Here's some data points:
- No plan to
2010/4/16 Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de
Am 16.04.2010 um 19:14 schrieb Marc-Antoine Ruel:
Please guys,
No need to speculate here on what I proposed at the session since Evan
somehow left some details out and let me reinforce some points. For those
who missed
Thanks Nico for digging up the archive.
As I said in the other thread, the people at the session mostly looked about
reducing the number of build system, not forcing anyone to use any tool. If
some teams wants to switch to CMake, prefect as long as the number of build
tool reduces. Nobody seemed
https://trac.webkit.org/wiki/ReviewTool
There was a fair level of interest but apparent lack of empowerment. :)
As Darin Alder said, bugzilla is basically a perl web application so it's
easy to plug in modules to add functionality.
In contrary, a brand new review tool is definitely a daunting
FYI, Chromium folks on Windows will be on python 2.6 real soon(tm).
The CL to bug them to upgrade should be committed within the next few
minutes.
[Thread hijack]
If you're not a Chromium-Webkit committer running on Windows, please
ignore the rest of this email.
Otherwise, please del
You didn't say on what flavor. I assume you are doing a release build.
If so, you probably need a x64 OS to link the static library.
You may want to install a few hotpatches from Microsoft,
http://dev.chromium.org/developers/how-tos/build-instructions-windows
lists a fews in addition to the ones
On Fri, Dec 18, 2009 at 1:51 AM, Brent Fulgham bfulg...@gmail.com wrote:
I've recently written an in-house NPAPI plugin for use with WebKit in an
application I'm working on. One of the primary functions of this tool is to
generate printed output, so naturally I was dismayed to discover that
On Thu, Aug 27, 2009 at 4:28 PM, Darin Fisherda...@google.com wrote:
On Thu, Aug 27, 2009 at 1:18 PM, Eric Seidel e...@webkit.org wrote:
On Thu, Aug 27, 2009 at 11:55 AM, Peter Kasting pkast...@google.com
wrote:
Maintaining a cultural attitude that is widely positive towards cleanup
makes
One workaround is to use a x64 OS to increase the available address space.
On Fri, Aug 21, 2009 at 12:19 PM, Yong Liyong...@torchmobile.com wrote:
I guess you've enabled link time optimization. The lib file is too big. The
solution suggested by MS is to split the project.
- Original
An hypothetical chromium builder should sync to
http://chromium-status.appspot.com/lkgr instead of HEAD. That'd fix most of
the builder failed to compile because chromium tree is broken.
lkgr stands for *last known good revision* in its weakest meaning. If
curious, more info at
FYI, Chromium port of webkit builds fine with VS2008. I'm pretty sure
it would be trivial for other ports. Did you try fixing the build
script by yourself?
M-A
On Wed, Apr 1, 2009 at 2:47 AM, Thomas Brodt thomas.br...@porabo.ch wrote:
BTW: How are the chances that VS2008 will be supported
Idea
One of the advantages of keeping the tree green is to enable the
implementation of a try server. We've been using that for a while and even
with its caveat, it's particularly useful when multiple platforms are
supported by a code base.
You can see it in action there:
Hi Alp,
About bug 16095 http://bugs.webkit.org/show_bug.cgi?id=16095, you wrote:
«
The added feature seems unusable since, even if the classes are subclassed,
there is still static code instantiating the base class in GraphicsContext. In
light of this, I think this patch is incomplete or wrong.
20 matches
Mail list logo
