Hey,
Keeping the GTK+ buildbot green has been a real challenge for many
reasons, but looking back at previous discussions we had regarding this,
I think we have come a long way. Over the last few weeks we (mainly
Xan!) put some hard work on getting the bot green by fixing bugs,
opening bug
Eric and I are working on a bot that might help this situation.
Essentially, the bot will try out patches on Qt and GTK and add a
comment to the bug if the patch regresses the build. Our plan is to
start with compiling, but we'd eventually like to run the tests as
well.
Of course, the bots won't
On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote:
Eric and I are working on a bot that might help this situation.
Essentially, the bot will try out patches on Qt and GTK and add a
comment to the bug if the patch regresses the build. Our plan is to
start with compiling, but we'd eventually
On Mon, Nov 16, 2009 at 3:33 PM, Gustavo Noronha Silva g...@gnome.org wrote:
On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote:
Eric and I are working on a bot that might help this situation.
Essentially, the bot will try out patches on Qt and GTK and add a
comment to the bug if the patch
15.11.2009, в 17:18, Yuzo Fujishima написал:
Reason 1: It connotes that the feature is experimental. That means
there
will be less developers seriously use that feature. Without serious
use,
we'll have less serious feedbacks from the real world. If the Web
Socket
has serious flaws, we
On Mon, Nov 16, 2009 at 5:56 AM, Xan Lopez x...@gnome.org wrote:
On Mon, Nov 16, 2009 at 3:33 PM, Gustavo Noronha Silva g...@gnome.org wrote:
On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote:
Eric and I are working on a bot that might help this situation.
Essentially, the bot will try out
On Mon, Nov 16, 2009 at 12:47 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
This is a huge issue with the Chromium port as well. We spend quite a
bit of effort tracking down failing tests, only to discover that the
failure is due to one-port baselines or new functionality added to
DRT. I
On Nov 15, 2009, at 9:57 PM, Chris Jerdonek wrote:
In particular, the following file uses using namespace WTF::Unicode five
times, but within the bodies of various template definitions:
http://trac.webkit.org/browser/trunk/WebCore/platform/text/BidiResolver.h
(see line 304, for example)
Hello,
I am interested in having broader support for non-scaling stroke on
SVG shapes. This is a SVGT 1.2 feature:
http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke
This adds a CSS property and attribute: vector-effect. This property
can have three values: none (default), inherit,
A try bot would help me a lot.
As others have mentioned, being able to see output from build+test is a big
deal.
I understand why you want to start with a Mac bot, and I applaud starting
small. However, bear in mind that lots of WebKit contributors work primarily on
the Mac, so they probably
I am contemplating a script to normalize the namespace indenting
across our code to match our guidelines, so I wanted to clarify two
things. First, it seems like the original motive was to avoid
pointlessly indenting nearly the whole file:
Hi,
I thougt that we already had a bug about this. It is a good idea to
support this feature in general. Even if our support for SVG 1.1 is not
perfect, we should think about some features of SVG 1.2 like media
support and also non scaling strokes. But implementing non scaling
strokes is not that
12 matches
Mail list logo
