taking a look at the weekly bugzilla summary, we see that the applications with the most bug reports filed per week are nautilus, evolution, totem and epiphany.
many of those crasher reports will be set to needinfo state, because the stacktraces will not contain enough information. okay, that’s life. but it’s bad for everyone, the developers, the vendors, the users, and the general reputation of gnome.
now, how to get faster and easier-to-provide information from a non-techie user? how to lower that barrier?
currently, the user will get a stock response which asks him to visit a webpage.
some users will think “hey, i’ve already helped them by filing my bug report, instead of cancelling. i’m not in the mood to spend additional time by reading through a webpage.”
the rest of the users will perhaps visit that GettingTraces wiki page (which was already rewritten by Elijah and split up to a Details page, to not demotivate the user by letting him read through hundreds of lines of uninteresting and techie stuff).
on that wiki page, we ask the user to install additional debugging information packages, and link to the DistroSpecificInstructions.
now, how many users think that this is getting complicated now, reading another webpage?
looking at that DistroSpecificInstructions page, we still cannot/do not tell the user which packages to install *exactly*, he has to find out on his own. being a non-techie user, would you be motivated to spend 15 minutes to do that?
i seriously doubt.
at least for those applications with the highest load, we should already provide an explicit stock answer explaining which packages to install (product specific debug packages plus the basic gnome stuff like gtk, glib, gnome-vfs and libgnome), so one does not have to visit a webpage anymore after reading the bugzilla mail. perhaps we also need to find a generic description *how* to install additional software packages, as i don’t expect every user to have already installed any additional stuff on his computer (“hey, it just worked out of the box, why should i have changed something/installed something?”).
perhaps, we should also add explicit information for the apps that get many reports with useless stacktraces, like EOG (137 needinfo bugs in the last 2 weeks, mostly totally empty stacktraces like this one), control-center (37 needinfo bugs in the last 2 weeks, mostly crashes in the sound component all looking like this one), yelp, or the gsearchtool of gnome-utils like this one.
dear developers of EOG, control-center, yelp and gnome-utils – which additional packages do you need to get better traces?
i’d be happy to get some feedback here (ak-47 at gmx dot net). or, did i miss any apps that also suffer from lots of reports with useless stacktraces?
thanks in advance for any feedback!
Maybe you could add an option in the programs menu “Add debugging packages for this program” and let the distro tie it in with their package manager. (A little like translate this program in ubuntu). Or maybe bug-buddy could be enhanced as to suggest installing debugging packages.
It’s a pity there is no standard method of specifying a package list to install. (RPM or DPKG based distros)
If that were the case, sets of a single download per distro could be supplied and a user could simply double-click and it would indicate to the local packaging system to install the appropriate debugging packages.
I remember seeing some specifications about these, at least in Ubuntu…
Oh the irony: clicking on ‘GettingTraces’ I get:
Traceback (most recent call last):
File “/var/www/blogs.gnome.org/blogs-web/nb/NBCGI.py”, line 107, in __init__
pathInfoProcessor() [etc]
On intial install, after the base packages are complete, a dialog says:
Thank you for installing Ubuntu/Fedora/XXX!
Help us make this software better. Installing debug
packages helps find the cause of bugs and fix them
fast. Installing debug packages will add 150MB to
your system.
Reboot Install Debug Packages
Fedora has debug packages separate from the program packages. Why not increase the distance of the separation and keep the debug packages on a server?
Look up the symbols in a stack trace after the stack trace is received. Perhaps you need some extra info in the stack trace, such as the version of the package installed or the md5 sum of the so file (RPM maintains md5s for all the files).
This would make a good web service. Each distro could host a server which you could query. Send it a file md5 and an offset and it returns an symbol name.
It doesn’t need to be that hard. Even if Gnome only supported extracting symbols after the fact from one distro, statistically, it would probably be enough. You mention 137 dupes above…
Either way, giving people a lengthy list of instructions to follow after their software has just trashed their work isn’t acceptable. Neither is a short list. If you can write a list of instructions, you can write a program.
Let’s solve this!
Tangentially, why aren’t those completely useless stacktraces being parsed and rejected by bug-buddy? Seems like a trace as empty as the one you linked to should never leave the PC. Perhaps, best case, you say ‘unfortunately, there is no useful automated information available. If you can give detailed information on what caused the crash, please do: _______________ [submit] otherwise, please [restart]
Or something like that.
well, if i’d be a coder, and not a destructive, complaining, whining guy that does not even know C, i’d try to code this myself, sure. however, my naive hope is that more people get aware of the problem that we DO have currently, and perhaps start writing some code/patches to improve this. :-/
@Baz: my fault – the first link in my blog entry is working, only the second one is broken. :-)
@Yo Baby: interesting approach to show that hint about the debug-packages – is there an explicit info on *how* to do install those packages? perhaps i should poke the ubuntu folks to also think about that…
@Luis: AFAIK, it’s not possible yet, because there is nothing to parse against. :-)
i _hope_ that bkor, guenther or nazgul take a look at this, but they are all pretty busy with other stuff. (hmm… looks like *everybody* is pretty busy currently, sigh) :-/
@Luis: uhm, correcting myself (i answered on the auto-rejecter, not on bug-buddy). yes, you’re definitely right. the earlier we reduce the workload, the better.
i filed a bug report about this:
http://bugzilla.gnome.org/show_bug.cgi?id=383349
My opinion on this matter ( and in fact on everything regarding easying some “important” things in linux ). Linux is not for total newbs who don’t want to spend an hour or two on learning some new things. I like that Linux is designed like that. You need to do something by yourself, the program doesen’t do everything for you.
On the other hand, i support the idea of better bug reporting/solving procedure.