RESOLVED FIXED 137626
Dashboard metrics page should have EWS statistics
https://bugs.webkit.org/show_bug.cgi?id=137626
Summary Dashboard metrics page should have EWS statistics
Alexey Proskuryakov
Reported 2014-10-10 15:17:41 PDT
Otherwise, how do we know it when we improve things. The UI is much more challenging than one for regular bots though, for multiple reasons: - EWS logic is a mystery to most, so we need to explain what any number means. - EWS is interactive, so patch processing result depends not just on EWS and the patch, but also on what happened with the bug and with trunk in the meanwhile. The patch could be obsoleted, or it could cease to apply because something else was landed while it was being processed. - There is a lot less publicly visible history, so we need to present more troubleshooting information.
Attachments
proposed patch (30.94 KB, patch)
2014-10-10 15:32 PDT, Alexey Proskuryakov
rniwa: review+
Alexey Proskuryakov
Comment 1 2014-10-10 15:25:38 PDT
Also because we can't hide any platforms - everyone looks at all platforms for EWS.
Alexey Proskuryakov
Comment 2 2014-10-10 15:32:21 PDT
Created attachment 239655 [details] proposed patch So the result is a sizable chunk of text for each queue, e.g.: mac-wk2 96% of patches had final results at first try. Time to result: - median: 47 minutes; - average: 43 minutes. This includes 8% that did not apply to trunk. 2% of patches ceased to be eligible for processing before the first try finished. 2% of patches had to be retried, including 2% that kept being retried until the patch became ineligible for processing. Median wait time before processing started: less than a minute.
WebKit Commit Bot
Comment 3 2014-10-10 15:33:56 PDT
Attachment 239655 [details] did not pass style-queue: ERROR: Tools/QueueStatusServer/handlers/processingtimesjson.py:61: whitespace before '}' [pep8/E202] [5] ERROR: Tools/QueueStatusServer/handlers/processingtimesjson.py:66: [ProcessingTimesJSON.get] Instance of 'ProcessingTimesJSON' has no 'response' member [pylint/E1101] [5] ERROR: Tools/QueueStatusServer/handlers/processingtimesjson.py:67: [ProcessingTimesJSON.get] Instance of 'ProcessingTimesJSON' has no 'response' member [pylint/E1101] [5] ERROR: Tools/QueueStatusServer/handlers/processingtimesjson.py:72: [ProcessingTimesJSON.get] Instance of 'ProcessingTimesJSON' has no 'response' member [pylint/E1101] [5] Total errors found: 4 in 10 files If any of these errors are false positives, please file a bug against check-webkit-style.
Ryosuke Niwa
Comment 4 2014-10-10 16:16:26 PDT
Comment on attachment 239655 [details] proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=239655&action=review > Tools/BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/BubbleQueueServer.js:-34 > + "gtk-wk2-ews": {platform: Dashboard.Platform.LinuxGTK, shortName: "gtk-wk2", title: "WebKit2\xa0Release\xa0Build\xa0EWS"}, > "mac-ews": {platform: Dashboard.Platform.MacOSXMountainLion, shortName: "mac", title: "WebKit1\xa0Release\xa0Tests\xa0EWS"}, > "mac-wk2-ews": {platform: Dashboard.Platform.MacOSXMountainLion, shortName: "mac-wk2", title: "WebKit2\xa0Release\xa0Tests\xa0EWS"}, > "win-ews": {platform: Dashboard.Platform.Windows7, shortName: "win", title: "WebKit1\xa0Release\xa0Build\xa0EWS"}, > - "gtk-wk2-ews": {platform: Dashboard.Platform.LinuxGTK, shortName: "gtk-wk2", title: "WebKit2\xa0Release\xa0Build\xa0EWS"}, Why are you moving GTK+ here? > Tools/QueueStatusServer/handlers/processingtimesjson.py:55 > + if not entry.attachment_id in result: > + result[entry.attachment_id] = {} result.setdefault(entry.attachment_id, {}) > Tools/QueueStatusServer/handlers/processingtimesjson.py:66 > + self.response.headers["Access-Control-Allow-Origin"] = "*" Should we use *.webkit.org & *.apple.com instead?
Alexey Proskuryakov
Comment 5 2014-10-10 16:28:52 PDT
> Why are you moving GTK+ here? Mentioned that in ChangeLog, it's to match the order of bubbles in Bugzilla. > > Tools/QueueStatusServer/handlers/processingtimesjson.py:66 > > + self.response.headers["Access-Control-Allow-Origin"] = "*" > > Should we use *.webkit.org & *.apple.com instead? We could, although not as easily. I don't think that it matters though.
Alexey Proskuryakov
Comment 6 2014-10-10 16:30:02 PDT
Note You need to log in before you can comment on or make changes to this bug.