Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

2014-01-17 Thread Alexey Proskuryakov

This has been implemented, and one unintended consequence is that this 
noticeably affects how quickly one can iterate on time sensitive patches.

It's a huge waste of time that you are no longer informed when a build fails on 
EWS. This seriously delays urgent work, as you only start working on fixes when 
you happen to manually poll, or even worse, when a reviewer tells you about 
build breakage.

It's good to not spam everyone, however patch author should be notified by EWS 
immediately I think. Some ideas:

- e-mail;
- IRC;
- browser notifications when bug page is open.

The latter might be best, as it also gives some control over whether to get 
pinged - keep the bug open if you care, close it if it's not urgent, and you 
cannot afford distraction now.

I filed https://bugs.webkit.org/show_bug.cgi?id=127203 about this.

- WBR, Alexey Proskuryakov


16 янв. 2014 г., в 15:09, Ryosuke Niwa  написал(а):

> Okay, let's remove the python paths but keep the style error messages until 
> we can improve the EWS infrastructure.
> 
> - R. Niwa
> 
> 
> On Thu, Jan 16, 2014 at 9:41 AM, Timothy Hatcher  wrote:
> On Jan 16, 2014, at 2:28 AM, Alexey Proskuryakov  wrote:
> 
>> 
>> 15 янв. 2014 г., в 23:02, Ryosuke Niwa  написал(а):
>> 
>>> I think that it's good to try not dumping build failures into comments 
>>> right away, and to see what happens.
>>> 
>>> As for not showing style bot failures, it seems almost certain that this 
>>> will make them substantially more annoying to work with. Can you describe 
>>> the workflow for patch author and reviewer to deal with style bot warnings 
>>> when they are not inline? Manually finding relevant lines by number can't 
>>> work.
>>> 
>>> I agree with Tim that dumping all tested paths along with style warnings is 
>>> silly. How hard would it be it to get rid of that?
>>> 
>>> The workflow is to click on the bubble to see the style errors. e.g.
>>> https://webkit-queues.appspot.com/results/6544662978363392
>> 
>> 
>> Seems like that would require everyone to manually match errors to code 
>> lines indeed, so I object against making this change for style checker 
>> warnings.
>> 
>> - WBR, Alexey Proskuryakov
> 
> Yeah, seeing the style warnings as a comment (which also causes them to show 
> up in the patch review) is helpful. I was just complaining about the python 
> path spew it also includes.
> 
> — Timothy Hatcher
> 


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


Re: [webkit-dev] Request for Comments: DoYouEvenBench

2014-01-17 Thread Ryosuke Niwa
I've finalized the benchmark and started making measurements on the perf
bots.  You can see results at https://perf.webkit.org/#mode=dashboard

You can run the benchmark inside DRT/WTR using run-perf-tests:
Tools/Scripts/run-perf-tests PerformanceTests/DoYouEvenBench/

To manually run, open PerformanceTests/DoYouEvenBench/Full.html.

You can also use the interactive runner to diagnose & profile WebKit:
PerformanceTests/DoYouEvenBench/InteractiveRunner.html

- R. Niwa

On Wed, Sep 18, 2013 at 5:30 PM, Ryosuke Niwa  wrote:

> Hi,
>
> I just added DoYouEvenBench, a new browser DOM benchmark, in
> http://trac.webkit.org/changeset/156073.
>
> This benchmark uses http://todomvc.com and emulates user actions: adding
> 100 todo items, completing them, and then deleting them with Ember.js,
> Backbone.js, jQuery, and plain-old DOM.
>
> I'm also in the process of adding one more Ember.js demo app and Flight JS
> demo app to the benchmark.
>
> The benchmark is at the very early stage of the development, and I'd
> welcome your comments and complaints.
>
> *Note: The benchmark is not meant to compare the performance between
> different JS frameworks.  Due to the way each application's written and
> user actions are emulated, we can't make a sensible comparison.*
>
> - R. Niwa
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev