[webkit-dev] On the greeness of the GTK+ bot
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
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
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
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
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
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
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
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)
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?
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
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)
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