Something always crashing, something not responding.
I’m collecting reports, but maybe it’s better to have ability to send them to bugtracker from interface?
E.g. like a checkbox “Send also report to developers”.
I think if developers will get fresh reports, maybe it’ll help them with fixes.
Just the crash report usually isn’t quite enough to debug. We will often need a lot more information. What were you doing? Did it happen only once or can you reproduce it with a specific scenario? did it work in an older revision, and if so, which one was it?
People willing to take the time to contribute all this information can also take the extra 2 seconds to upload the report in their ticket. People wanting automated bugfixes without interaction with the devs and only an automated support... well, this won't work.
Try “BeSly System Analysis Tool”, this tool collect your system data and other informations. This informations can be export to send them to BUGTracker:
Frankly this is much less true than PulkoMandy makes out, particularly for application crashes. Nevertheless an automated submitter can easily leave space for users to write a few notes when they’re generously submitting the information. If you look at something like Mozilla they track failures automatically, they have tools that look for patterns and that lets them use limited resources to work on the problems affecting most people, and avoid wasting time on a crash that only seems to trip up one person whose RAM is probably fried.
Much more pertinent though is the simple fact that Haiku has very few volunteers and they’re not terribly interested in mundane stuff like this. Capturing the bug reports makes no difference to whether anybody is going to investigate, fix the problem and ship an update with the fix.
FWIW, I think it would be a useful addition, since it will help spot the most lacking areas in Haiku. No one is forced to fix anything, but having the data is always beneficial.
No, it is not. It means effort on our side to triage the data. It means we are possibly collecting personal data from users so we need to be careful about what we do with it. It means people will think “it’s fine, I clicked the button in the crash report dialog, I don’t need to do anything else” instead of creating an issue and giving actually useful details on how to reproduce the problem and being available to answer our questions about it.
We will just be collecting gigabytes of data that no one can make sense of.
If we are to do something like this, we need to think about it the other way instead: why do we want to collect the information? How do we process it? How can it improve the workflow for both users and developers? And then design the appropriate tools to do it. But “let’s put a huge pile of bugreports with no or limited context on an FTP server” is not fixing anything or help anyone.
Building the tool that makes sense of all the bugreports, groups them together, and possibly even suggest exisitng bugreports to look at for users hitting a particular crash is possibly not that “mundane”. And that is the part that would turn mostly-useless data collection into something that can possibly help us.
Personally, I’m trying to do my share of mundane tasks, currently that is reviewing, cleaning up and merging the hundred of patches we have on Gerrit, as well as triaging existing bug reports and trying to sort out what goes in R1 and what can be done later. What’s the point of fixing bugs if there are so much pending changes that we don’t even take the time to review and merge them?
In one desktop software project I work on we get automatic crash reports, and honestly these are mostly useless garbage if the user does not give additional details on what they were doing. IMHO this is neither good for the developers not the users. At some point developers stop caring if too many of those reports turn out to be non-actionable. And users get frustrated because they think they have contributed and reported an issue, but see that nothing happens.