Some of you might remember our good old crash reporter, it was a nice tool. But maintaining the server part was not so nice. So, when I was planning to resurrect the server part I asked myself; why? Can’t this just be done on the user side?
So, I dropped our existing crash parser (stackwalker) and just made a simple library that parses crash dumps locally (if symbols are present) and outputs it in plain text.
Now when you get the crash dialog you will see the actual crash and be able to submit it to GitHub directly.
This seems like it has the potential to add a lot of issues to the GitHub repo, having options to file a bug report or to just upload the crash report (maybe to a different repo?) might be a nice way of managing that? As a user I don’t want to add issues needlessly however (as far as I understand it) having a collection of crash reports to search through might be helpful when tracking down bugs.
Oh absolutely better to get more data with actual bug reports but if you’re looking to build a library of crash reports to search over this might result in a flood of issues where many users don’t know exactly why it crashed instead of reporting specific reasons issues. As a user I sometimes don’t really know why a program crashed and when I have the option to send a report along I do but often (if given the option) I wouldn’t make a GitHub issue out of it because I typically only make issues when I know exactly what is wrong so it is clear what needs to be fixed.
In short, this is great if you already want to submit a bug report but bug reports aren’t always the same as crash reports.
I agree with @Shrinks99 that this will probably flood the github issues.
If you really want to use github for that, you should create another project in the NatronHitHub org, eg NatronCrashReports, which is dedicated to that.
We can still refer to these issues from the (curated) Natron issues.
