[webkit-dev] Requesting feedback about EWS comments on Bugzilla bugs

[Guillaume Emont]

I agree with Tim's suggestion of limiting the comments to only one
immediate comment saying "at least one EWS failed" and referring to a
web page that summarizes everything. That could cover what is done by 1)
and 2) in a more elegant way.

I'm not sure 3) would make a big difference for me, but I'm not against
it.

I think 4) is necessary, and I imagine it would solve pretty easily a
lot of the issues that people have with these comments (like the example
of #177484 you gave).

I'm not too sure about 5). I like to have all that info easily
accessible from one place (the bugzilla issue), I'd rather not have to
juggle between that and my email client. Also, if it's only emailed to
the author of the patch, it won't be as easily available to people who want to
follow what's happening with a bug (for review or other purposes) and/or
help with some issues.

Anyway, my 2 cents on the issue, hope it helps.

Guillaume

Quoting Aakash Jain (2019-06-16 06:13:19)
> 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.
> Pros:
> 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. 
> 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)
> 
> 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.
> 
> 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.
> 
> What do you guys think?
> 
> Thanks
> Aakash