38

I think there is a potential for a win-win: easier to report and better-quality information.

The more information is gathered automatically the more reliable it will be, and the more it will be reported in a consistent format which can allow reports to be automatically collected together.

So long as you have a good way of dealing with it more information is always better.

Another idea that could be useful (I'm certain I'm not the only one to have thought of this) is a backtrace service so rather than downloading the whole dubug-symbols package, a user who uses binary packlages could send their raw backtrace to a server (run by their distro) that would look up just those symbols and return the human-readable backtrace. This is asking something of the distro but on the other hand looking up backtraces could be less costly that the bandwidth required to serve users with the full debug packages. Ideally this would happen silently (without more than a single "OK" click from the user).

Almost all the comments here are based on what users want in order to submit bugs, where the important question is
"What do developers want?"

From my development POV I want user's email address so that after I've fixed it, and a new release is out I can ask "has your problem gone away now?"

Having lots and lots of bug reports all for the same bug isn't going to improve the quality of KDE. I don't think having 10 backtraces would be any more useful than just one. Lots of low quality bug reports is more triaging, with (IMHO) little gain.

@maninalift - that's a pretty nice idea in theory, though I'm not sure how certain you can be that the symbols in a debug build would be the same as that of a non-debug one. I wouldn't be surprised if they don't line up - by definition the debug one will have more stuff in, and so symbols will probably be offset.

Can we at least get the packages to install correctly? One of the reasons I hate bug reporting is the fact that it asks me to install debug packages, but then says that there are no debug packages available, but continues to install another 5 minutes worth of debug related stuff (when an mp3 file will take around 4 seconds...). And of all things, this keeps happening to me with Dolphin. Bare minimum, this shouldn't be such an issue to file a bug (that never gets filed, because the report is never good enough) for such a common program.

Debug-packages should not be always installed.
Although with big hd's there can be problems, e.g. you can have multiple systems (recently I installed openSuSE with KDE on a 10GB partition, because the rest was covered by Mac OS X with a lot of images).
Bugreporting with DrKonqi is really simple.
I do not see any useless fields.
But the functionality should be improved:
1. A proper library that provides everything you need for bug-management. It could also be used in Akonadi or KDevelop etc.
2. A DrKonqi-like dialog to report normal bugs and feature requests.
3. A frontend providing all the features from bugs.kde.org for further discussion...

Login is important, but maybe there could be a simple field in DrKonqi for your EMail and your openID.

@david_edmundson

I agree the focus should be on what the developer needs to identify and solve bugs. Including email is good. but don't you agree that by collecting the information you can automatically you rather than asking the user to fill in a form providing information about e.g. their platform you (1) get information in a more consistent reliable format and probably more of it and (2) make the process of a crash rather easier for the user thus to some (if small) extent mitigating it's effect (not that old WTF? my program has crashed and it's just launched my email client).

maninalift wrote:@david_edmundson

I agree the focus should be on what the developer needs to identify and solve bugs. Including email is good. but don't you agree that by collecting the information you can automatically you rather than asking the user to fill in a form providing information about e.g. their platform you (1) get information in a more consistent reliable format and probably more of it and (2) make the process of a crash rather easier for the user thus to some (if small) extent mitigating it's effect (not that old WTF? my program has crashed and it's just launched my email client).

Fedora's abrt does all this. It tries to gather the information, if it can't it tells you which debug packages it needs and offers to download and install them. If you accept that it re-runs the information gathering. It then asks you for your login information, makes the connection and files the bug report.

From a user PoV it's good, but the result is dozens and dozens of duplicate bug reports. I doubt if the triagers are quite as thrilled. In theory it scans for existing matching bug reports, but it's not terribly successful. This needs serious improvement before it works well for developers.

Of course, it's likely that abrt will appear in other distros too, if it is found to 'fit the bill'.

The User wrote:Login is important, but maybe there could be a simple field in DrKonqi for your EMail and your openID.

Then my point isn't clear enough on the login-part.
- Why should there be a login?
- What benefits do I as a user get?
- Is it worth the trouble? (I know I know it only takes 5 minutes, but still I don't want to use those 5 minutes on creating another user)
- Isn't whatever reasons you can come with acchieved by asking for an e-mail?

If you don't believe me on the point that I'm trying to stress - a lot of people don't want to bother creating users, I think you should wonder why sites like bugmenot.com and 10minutemail.com exist.

As long as you don't give me a really good reason to why login is actually important I see no reason to change my mind.


But ok, for the rest of the debate I sort of see too parts:
The end-user point of view, where it seems most people agree that my proposition is actually quite good.

The developer point of view, where there is a lot of technical details onto: How to avoid duplicate bugs and how do we get the right information.

Also it seems that most people here agree that the quality of the information and prevention of duplicate bugs should be done by the system, not the user. So this more or less ends up ind, how can we improve this and at the same time make things more user friendly?

Is this more or less a correct summary of what everybody seem to agree on?

Login is important to allow a further discussion. The reporter gets the benefits that he can follow the discussion and give hints/answer questions.
When it would not take 5 minutes but 20 seconds (insert email and openid) it would definitely be worth the effort. Accounts are simply easier to handle.

I do not agree that the system can filter duplicate bugs, an automatic duplicates-detection is unimplementable I think.

The User wrote:Login is important to allow a further discussion. The reporter gets the benefits that he can follow the discussion and give hints/answer questions.
When it would not take 5 minutes but 20 seconds (insert email and openid) it would definitely be worth the effort. Accounts are simply easier to handle.

Ah but isn't this also achieved by having a system where everybody can write and voluntarily put their email here? A bit like blogs do, eventually combined with OpenID (like a lot of blog systems do).

I believe OpenID is a major improvement, but really I would prefer a system where the user-part etc. is 100% optional.

The User wrote:I do not agree that the system can filter duplicate bugs, an automatic duplicates-detection is unimplementable I think.

I won't be able to tell that, since I know nearly nothing about the info provided by these systems and nor do I know much about bugfixing in C++. But making it perfect might not be the goal, but if it can improved that in itself is to be desired.

How should a software decide if two bugs are identical?

The User wrote:How should a software decide if two bugs are identical?

Well now I'm more into Java and C# than C/C++ but in those two identical stack traces from an exception would be a good start.

Btw. as far as I can see the current tool didn't bug me with bugs that are potentially identical to mine, so I guess there isn't much happening on this part anyway (which I consider better than bugging the user with it). So I if I'm not mistaken doing mine wouldn't affect on the duplicate bugs part except for the potentially more bugs provided.

Short version (because AJAX destroyed my first comment):
Sorry if it is a bit harsh, I'm a bit tired of explaining this

- Bug reports are useful to *developers* (not for users.) Users will only benefit in the end if the bug is fixed. (and if it was a real bug; a lot of reports aren't KDE bugs)

- Feedback is needed 95% of the times, even if the automatically collected information is valid and complete. Experienced developers may identify patterns in your situation and ask you for more information (specific details) about your system or the actions you took prior to the crash. (like "did you clicked Plasma panels prior to the crash", or "do you have driver X at version Y"; this kind of information can't be fetched automatically prior to the crash, because it is out of the context of a general crash)
With more information the original report can be turned into something useful, and be used to identify and fix the crash/bug

- A lot of manpower is needed to handle more than 250~ bug reports that are filed per day on the KDE bugtracker. Some of them are filed using 10-minutes mail-accounts, and those are closed because lack of feedback.
KDE Triagers Group currently lack manpower, so, allowing even *more* bug reports come in (and even, *without a possibility for feedback*) is a big **NO**. They can't handle that in our current state, sorry

- DrKonqi implements a lot of filters to only report bug situations that may be helpful, or when the user knows the crash context; or if the user doesn't know but he/she is *willing to provide feedback*. Since KDE SC 4.4, the first DrKonqi screen WARNS you that developers ARE going to contact you, and if you don't want you, you MUST close the assistant...
Also, the second screen asks you about how much information do you know, or how much you can provide. If you don't "pass" this filter.. the report is canceled.

- Since KDE SC 4.5, DrKonqi doesn't show the backtrace to the user anymore because it is not important. Some other functions were polished to not show internals/technical details to the user. (to not confuse him/her)

- DrKonqi should now detect the missing debug symbol packages and suggest the user to install them. Having them installed from the start is a decision the distributions must take... (unrelated to KDE) Debug package installation is handled by distribution-dependant scripts (until KDE Platform has an integrated package management lib, Shaman2)

- Possible bug duplication is performed using the functions in the stacktrace; using a query on the bugzilla database. (it should be even smarter since KDE SC 4.5). However, even with similar stacktraces, the crash could be different (or the same), so the user checks that and suggest possible duplicates. (user could skip this step and give it to the triagers..)

- I don't have any opinion on OpenID, only that implementing it will require modify/adapt Bugzilla in someway... (and may be DrKonqi too)

---

As a final conclusion: the improvements you suggested could only be integrated if KDE community had a *LOT* of bug triagers to keep the database clean and ordered. (it is the sad truth)
SPAM -> "Get Involved in Bug Triaging for KDE!" -> http://techbase.kde.org/Contribute/Bugsquad

--
Just my two cents as former dev of DrKonqi and former bug triager (for more than 2 years.. )
Regards
Darío A.