Marcel,
I would certainly like to echo your call for more wide spread use of the
error reporting tools by all projects. There is a wealth of information
here. The fact that you're very responsive to improvements is also a
huge win for the committer community.
Thanks so much!
Cheers,
Ed
Hello cross-projects,
> On 06 May 2015, at 13:54, Ed Merks wrote:
> I would like to suggest that the "blame" logic should consider that
> Display.readAndDispatch processes events of arbitrary origin.
I spent some time analyzing how large the effect of such a change would be. I
judged all dif
Maybe I worded mine badly, but I was after pretty much the same as Ed ;P
(maybe with the addition that I would take the cut-off trace as a base
for all subsequent analysis - blame, duplicate detection, ...)
On 06.05.2015 14:56, Marcel Bruch wrote:
> Thanks for the feedback Ed. I understand your c
Thanks for the feedback Ed. I understand your critique with the current blame
logic. Unfortunately cutting off / ignoring frames below Display.runAsync or
Display.runDeferred can have the opposite effect (missing the project that
scheduled the ui runnable). I remember stacktraces that contained
For cutting off the stack frames at Display.readAndDispatch() there's
already https://bugs.eclipse.org/bugs/show_bug.cgi?id=451359.
On 06.05.2015 13:54, Ed Merks wrote:
> Marcel,
>
> The error reporting tool is extremely cool and very useful!
>
> One aspect that could likely be improved signific
Marcel,
The error reporting tool is extremely cool and very useful!
One aspect that could likely be improved significantly is the
computation of the "blamed" projects. In particular I'm having to
triage many reports such as this one:
https://dev.eclipse.org/recommenders/committers/confess/#
