[webkit-dev] Requesting feedback about EWS comments on Bugzilla bugs
timothy_horton at apple.com
Sat Jun 15 22:15:21 PDT 2019
> On Jun 15, 2019, at 21:13, Aakash Jain <aakash_jain at apple.com> wrote:
> Hi Everyone,
> I am gathering feedback about EWS - specially about the comments which EWS makes on the Bugzilla bugs. Currently, the comments are not very user-friendly/polished/readable and are sometimes very noisy (e.g.: 72 comments and 36 attachments by EWS in https://bugs.webkit.org/show_bug.cgi?id=177484). I am working on improving them and looking for specific ideas/feedback.
> Few ideas which I am considering:
> 1) Do not upload archive (for layout-test-results) on bugzilla, instead upload it to another server, unzip it and post a link to the results.html.
> a) Engineers won't have to download the attachment, unzip it, look for failures, and then delete it from their disk. They can simply click the url to view the results.
This would be nice!
> b) This approach will also reduce 2 comments per failure to 1 comment. Currently there are two comments per failure, one for failure details, second for bugzilla attachment.
> 2) Aggregate comments from multiple queues.
> Pros: less noise
> Cons: comments would get delayed while waiting for results from other queues. (Also might be little complex to implement)
Maybe post a comment that says just “some queues failed” when the first one fails, with a link to page on another server that lists the failures (and pending queues)? That way you can still have only one comment and do your coalescing, but it doesn’t have to wait for all to be done before commenting?
> 3) Improve the text of the comments to make them more readable (specific ideas are welcome).
> 4) When a patch becomes 'obsolete', tag the corresponding EWS comments as 'obsolete', so that they will be hidden.
This would be great.
> 5) Do not comment on bugzilla bug at all, instead send email to the author of the patch.
> Pros: less noisy, also this will allow to include more detailed information about the failure in email.
> Cons: reviewers would have to click status-bubbles to see the failures, failure information is not immediately present in the comments.
I feel like “I have to click the status bubbles” isn’t so bad. That’s what we do for build failures (they don’t comment) and nobody complains about that...
> What do you guys think?
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev