[webkit-dev] On the greeness of the GTK+ bot

2009-11-16 Thread Gustavo Noronha Silva
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 reports, and skipping tests.

One of the issues we usually have lots of trouble with is patches
regressing our tests that people do not notice. We have had some good
experiences regarding this recently: a patch to modify how the media
tests were run broke all our media tests for the third time since we
stabilized them, but the change was backed out to be reworked.

The second one was the work to get shadows support in cairo, which
regressed 2 tests of ours. Because we were paying attention we were able
to quickly spot them, and the people involved could fix them before
their regressive nature was lost in time, and they ended up on the
Skipped list.

I would like to ask of people checking in changes that they try to pay
as much attention to our release bot as they are paying to Mac bots. We
will do our best to keep them green, but it gets very difficult to do it
when people are checking in stuff that breaks our tests all the time,
and not paying attention to them. In summary, I would like to see this
kind of behavior applied to our bots as well:

https://bugs.webkit.org/show_bug.cgi?id=29329

This it can't remain like that; we need to either skip, check in a
platform-specific result or back out the change would help us a lot.

Thanks!

P.S. I think it is important to note there are a number of tests failing
intermittently, mainly inspector ones, but that seems to be happening on
all the bots, so bear with us there =).

-- 
Gustavo Noronha Silva g...@gnome.org
GNOME Project

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] On the greeness of the GTK+ bot

2009-11-16 Thread Adam Barth
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 guarantee that folks won't break the GTK
build, but at least they'll be breaking it with malice aforethought.

Adam


On Mon, Nov 16, 2009 at 5:06 AM, Gustavo Noronha Silva g...@gnome.org wrote:
 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 reports, and skipping tests.

 One of the issues we usually have lots of trouble with is patches
 regressing our tests that people do not notice. We have had some good
 experiences regarding this recently: a patch to modify how the media
 tests were run broke all our media tests for the third time since we
 stabilized them, but the change was backed out to be reworked.

 The second one was the work to get shadows support in cairo, which
 regressed 2 tests of ours. Because we were paying attention we were able
 to quickly spot them, and the people involved could fix them before
 their regressive nature was lost in time, and they ended up on the
 Skipped list.

 I would like to ask of people checking in changes that they try to pay
 as much attention to our release bot as they are paying to Mac bots. We
 will do our best to keep them green, but it gets very difficult to do it
 when people are checking in stuff that breaks our tests all the time,
 and not paying attention to them. In summary, I would like to see this
 kind of behavior applied to our bots as well:

        https://bugs.webkit.org/show_bug.cgi?id=29329

 This it can't remain like that; we need to either skip, check in a
 platform-specific result or back out the change would help us a lot.

 Thanks!

 P.S. I think it is important to note there are a number of tests failing
 intermittently, mainly inspector ones, but that seems to be happening on
 all the bots, so bear with us there =).

 --
 Gustavo Noronha Silva g...@gnome.org
 GNOME Project

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] On the greeness of the GTK+ bot

2009-11-16 Thread Gustavo Noronha Silva
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 like to run the tests as
 well.

That sounds like an awesome idea. Thanks for working on it. Build
breakages themselves have become less of an issue for us in recent times
- people are definitely more aware of our bots, and are acting on fixing
them when they break.

I think such an automated approach to running the build, and tests for
upcoming patches will surely help with giving this a second step
forward.

See you,

-- 
Gustavo Noronha Silva g...@gnome.org
GNOME Project

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] On the greeness of the GTK+ bot

2009-11-16 Thread Xan Lopez
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 regresses the build.  Our plan is to
 start with compiling, but we'd eventually like to run the tests as
 well.

 That sounds like an awesome idea. Thanks for working on it. Build
 breakages themselves have become less of an issue for us in recent times
 - people are definitely more aware of our bots, and are acting on fixing
 them when they break.

 I think such an automated approach to running the build, and tests for
 upcoming patches will surely help with giving this a second step
 forward.

This is nice to see, but as Gustavo says build breakage is not too
much an issue at the moment for us: the build does not break very
often, and when it does people usually take the time to figure out
what happened and either do fix it themselves or poke us about it.
That being said, this could be improved in any number of ways and I'm
happy to see it getting ever better.

What is effectively a black hole with respect to our time is the tests
breakage, though. We get new tests failing very regularly (either
through new tests or through new code making old tests fail), and once
the bots are red people tend to pay even less attention to them, so
they spiral out of control in a positive feedback loop until we have
tests failing in the double digits in a matter of days (or hours!). Of
course in an ideal world we'd have a team big enough to always have at
least one person looking at this and fixing the problems the moment
they arise, but unfortunately this is not the case.

I realize this is a very complicated problem to fix unless we throw
more people at it from our side, but maybe we could all agree in some
basic guidelines to make things a bit better:

- If you are adding new functionality + tests that you *know* will
fail in some bots, open a bug describing what we should implement to
get it working, and skip all new tests with a reference to the bug
number. This should be relatively easy to do for the person who
implemented the functionality in the first place, and would save
everyone lots of time in the long run.

- If your new code makes a previously passing test(s) fail in a port
other than your own, you have two choices:
  * If you know what's going on and think this is a bug in the port,
you can propose a patch yourself, or open a bug with your ideas and
skip the tests with a reference to the bug number. Get the port
maintainers on the loop ASAP.
  * If you have no idea of what's going on, maybe Eric's proposed
hard-line policy kicks in: you either figure it out quick and propose
something, or the patch is rolled out until things are clear;
regressions in tests in any port are as bad as build breakages, so
early roll out is preferred to having the bots red for a long time.

As I said, this is a complex problem, but I think at the very least
having a clear picture of what is expected of everyone with respect to
failing tests in the bots would be a good start to make things easier.

Xan


 See you,

 --
 Gustavo Noronha Silva g...@gnome.org
 GNOME Project

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Staging WebSocket protocol deployment

2009-11-16 Thread Alexey Proskuryakov


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 should rather know them sooner than later. I'd  
say

only serious uses can help us find the flaws faster.



It doesn't seem that wide use is possible before the protocol evolves  
into something that works with all proxies - or before a heavyweight  
service forces network administrators to update their proxies for  
compatibility with the existing protocol. Frankly, I think that the  
former is more likely.


The only case that is likely to work on Internet reliably right now is  
running over SSL, which negates some of the protocol's strengths - it  
will no longer be as efficient as it's meant to be. In order to enable  
port sharing, this also requires one to serve documents over https,  
which is an additional cost.



Reason 2: What should other browser vendors do? Should they use
chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least  
developers
will not happy with that. If the vendors need to reach the consensus  
on the
common experimental name, say prelim-ws, then why not just use ws  
instead?


In practice, this means half a dozen lines of browser detection code -  
which does not matter when deploying a technology of this magnitude,  
as already mentioned in this thread.


It seems that a common argument against using a name other than ws  
is that a scheme is just an opaque identifier, so it doesn't matter  
which name to use, so we can just change the name later, if necessary.  
I don't think that this is a strong argument - if the name doesn't  
matter in the long run (which I wouldn't agree with, but anyway), why  
sweat about what the name is during experimental rollout of the feature?


- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] On the greeness of the GTK+ bot

2009-11-16 Thread Dimitri Glazkov
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 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.

 That sounds like an awesome idea. Thanks for working on it. Build
 breakages themselves have become less of an issue for us in recent times
 - people are definitely more aware of our bots, and are acting on fixing
 them when they break.

 I think such an automated approach to running the build, and tests for
 upcoming patches will surely help with giving this a second step
 forward.

 This is nice to see, but as Gustavo says build breakage is not too
 much an issue at the moment for us: the build does not break very
 often, and when it does people usually take the time to figure out
 what happened and either do fix it themselves or poke us about it.
 That being said, this could be improved in any number of ways and I'm
 happy to see it getting ever better.

 What is effectively a black hole with respect to our time is the tests
 breakage, though. We get new tests failing very regularly (either
 through new tests or through new code making old tests fail), and once
 the bots are red people tend to pay even less attention to them, so
 they spiral out of control in a positive feedback loop until we have
 tests failing in the double digits in a matter of days (or hours!). Of
 course in an ideal world we'd have a team big enough to always have at
 least one person looking at this and fixing the problems the moment
 they arise, but unfortunately this is not the case.

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 wonder if the approach we have today in regards to tests is not
sustainable with multiple vibrant ports, each spending way to much
time catching up.

:DG
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] On the greeness of the GTK+ bot

2009-11-16 Thread Ryan Leavengood
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 wonder if the approach we have today in regards to tests is not
 sustainable with multiple vibrant ports, each spending way to much
 time catching up.

This is also a big concern for our tiny group working on the Haiku
port. While we are not nearly at the stage of GTK, Qt or Chromium, we
hope to get there one day, and it would be frustrating to have our
tests broken or our (future) build bot constantly red due to other
port's changes.

Given how many people are having pain with this, it seems some change
might be warranted. Unfortunately I don't feel qualified enough to
suggest anything.

But I think there is enough cumulative experience on all sides to come
up with a good solution.

-- 
Regards,
Ryan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] using namespace style guideline

2009-11-16 Thread Darin Adler
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)
 
 Is this also not okay?

This is fine.

If the using namespace is scoped to a particular function, then it’s not the 
same thing we’re talking about.

 The following is another example.  The using statement for this one appears 
 at the beginning, outside of any definitions, but the file seems to be 
 central:
 
 http://trac.webkit.org/browser/trunk/JavaScriptGlue/JSUtils.h
 
 It uses using namespace JSC.

JavaScriptGlue does not follow the WebKit coding style — there’s no need to 
look at files inside the JavaScriptGlue directory when considering matters of 
style.

 My second question is whether the guideline above should apply, for the same 
 reason, to all using statements within header files -- and not just to 
 using namespace statements.  Statements of the form using WTF::... would 
 be exceptions.  You've already discussed those here:
 
 https://lists.webkit.org/pipermail/webkit-dev/2009-November/010453.html
 
 I checked, and there are only about 40 files in all of WebKit that wouldn't 
 currently be following this -- slightly less than half of which are in JSC.

Probably. We’d have to discuss specific examples to be sure.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Non-Scaling Stroke feature (SVGT 1.2)

2009-11-16 Thread Jeff Schiller
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, or
non-scaling-stroke.

When non-scaling-stroke, the stroke (outline) of a shape would
maintain its specified width regardless of the transforms applied to
the shape.  This is very useful when importing foreign SVG into new
documents and in GIS/mapping scenarios (for instance, zooming in on a
map would not fatten the driving directions path).

I realize that WebKit has been generally not interested in SVGT 1.2,
but I feel it makes sense to cherry-pick certain features that really
do improve SVG on the web.  Non-scaling stroke is one of these
features.  FWIW, Opera has implemented this feature since version 9.5.

I have opened a bug and supplied a patch that gets this off the ground
in WebKit:  https://bugs.webkit.org/show_bug.cgi?id=31438  I only need
to figure out how to add some tests (need to understand how pixel
tests work in WebKit).

Darin Adler requested that I bring this up on this list for discussion.

Thanks,
Jeff Schiller
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] A bot-filled future?

2009-11-16 Thread Geoffrey Garen
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 won't get any use out of a Mac try bot, and you 
probably won't get any feedback from them until the try bot expands to cover 
other platforms.

Geoff

On Nov 12, 2009, at 11:37 AM, Adam Barth wrote:

 As the project grows, we need to scale our processes to match.  In
 large part, that means automating as much work as possible.
 Commit-queue has done a good job of solving the land patches from
 non-committers efficiently problem, effectively removing that as a
 pain point.  I'd like to ask you to open your hearts and your minds to
 the idea of automating more of our processes.
 
 Currently, I see the biggest pain-point in our process as the
 always-burgeoning pending-review list.  It's difficult to automate the
 process of accepting good patches because that requires attention from
 experts.  Instead, I think we should make it easier to reject bad
 patches.  As a first step, I've started extending bugzilla-tool to be
 a try server in https://bugs.webkit.org/show_bug.cgi?id=31422.
 Here's how this might work:
 
 1) Contributor posts patch for review.
 2) Committer marks patch with the try? flag.
 3) The try-queue downloads, applies, builds, and tests the patch.
 4) If all systems are go, the try-queue marks the patch as try+.
 Otherwise, it marks the patch as try- with an explanation of what went
 wrong.
 
 The try-queue will be purely optional and advisory.  Hopefully a try-
 notation will encourage the contributor to post a new version of the
 patch that passes the try-queue.
 
 Further down the road, one can also imagine another bot that automates
 step (2) by scanning the pending-review list for untried patches and
 marking them as try? when the try-queue has unused bandwidth.
 
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] normalizing namespace indenting

2009-11-16 Thread Chris Jerdonek
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:

https://lists.webkit.org/pipermail/webkit-dev/2009-September/010002.html

So, I was wondering if we can clarify the rule to apply only to the
outermost namespace declaration.  Otherwise, files with nested
namespaces like the following become harder to read:

http://trac.webkit.org/browser/trunk/JavaScriptCore/wtf/FastAllocBase.h

(Consecutive declarations like namespace JSC { namespace WREC {
would be treated as a single declaration for the purpose of this
rule.)

Second, do people prefer nested namespace blocks to end with the
fully-qualified name (e.g. // namespace JSC::WREC) or just the final
name (e.g. // namespace WREC)?  I have seen both.

--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Non-Scaling Stroke feature (SVGT 1.2)

2009-11-16 Thread Dirk Schulze
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 easy. On SVG we transform the context multiple times
(translate, scale, skew) and stroke the path at the end. We may think
about transforming the path instead of the context but there might be
more problems on doing that.

-Dirk

Am Montag, den 16.11.2009, 16:23 -0600 schrieb Jeff Schiller:
 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, or
 non-scaling-stroke.
 
 When non-scaling-stroke, the stroke (outline) of a shape would
 maintain its specified width regardless of the transforms applied to
 the shape.  This is very useful when importing foreign SVG into new
 documents and in GIS/mapping scenarios (for instance, zooming in on a
 map would not fatten the driving directions path).
 
 I realize that WebKit has been generally not interested in SVGT 1.2,
 but I feel it makes sense to cherry-pick certain features that really
 do improve SVG on the web.  Non-scaling stroke is one of these
 features.  FWIW, Opera has implemented this feature since version 9.5.
 
 I have opened a bug and supplied a patch that gets this off the ground
 in WebKit:  https://bugs.webkit.org/show_bug.cgi?id=31438  I only need
 to figure out how to add some tests (need to understand how pixel
 tests work in WebKit).
 
 Darin Adler requested that I bring this up on this list for discussion.
 
 Thanks,
 Jeff Schiller
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev