still thinking of how to get better and faster feedback (and less useless reports – thanks to fer for rejecting empty stacktraces in bug-buddy), we’re still closing way too many needinfo bugs as incomplete.
one idea: stock responses providing direct info which debug packages to install on a per-app basis (more feedback welcome).
also, there was a nice comment to my last blog entry by a reader named Yo Baby:
when installing community distros, add a
"Thank you for installing $YOUR_FAVORITE_DISTRO! If you like to help making GNOME better and have enough free diskspace, we kindly ask you to install additional debug packages that make finding the cause of bugs and fixing them easier and faster after reporting them. Installing those debug packages will approximately add $WHATEVER MB to your system."
and add a *direct* option to install them.
i assume that vendors would be interested in better quality, less crashers, and happy users?
so is this doable, at least for ubuntu/fedora/suse? is this a good idea at all, or should i just go to sleep now? :-)
(and do i have to poke folks directly to get this done instead of getting a “nice idea, would be cool to get this done by somebody, but not me” response?)
ubuntu 7.04, fedora 7, suse 10.3, where are you?
As a user, this would be very useful. It’s not always obvious what’s needed to get a book backtrace
I agree, I feel bad whenever I submit a bug through bug-buddy because I know it’s probably already been reported, and I’m just making more work for someone else. I completely back anything to make developers’ lives easier…
Why not, if it doesn’t affect normal operation (ie. performance of the applications).
As a member of the Fedora QA team I can say that we spoke about good ways to do this only just last Thursday. We were actually hoping we could work with upstream to find a common way to provide a means of easily installing debug symbols. Bug-buddy is an obvious place to attack this problem.
Naturally we don’t want to ship debuginfo packages installed by default in production environments but I have personally been pushing for it to be the default for our Development branch.
Great to hear that there’s interest in making this Just Work ™.
Sounds nice! it would really improve the backtraces, however how are you thinking to installing? am I seeing a package manager abstraction layer or something like that? (because it would be great to have a totally working gnome frontend for pacman).
I hope you have luck pocking guys around.
We had a session at Gnome summit about doing this the other way around: you submit the bugbuddy backtrace to the server along with package EVR info, and it grabs the debuginfo for you and decodes it. The main reason being that debuginfo is huge, many users still use dialup, and it’s more efficient to keep the debuginfo packages centralized anyway.
I’m curious why dbg packages are neccassary? On Ubuntu, when something crashes, our apport app sends the core file. Can’t this core file be taken, along with the distro specific dbg packages, to produce a meaningful backtrace for Gnome?
I sort of think that this would be ideal. Let the distro be the first level of support.
Jerry: That is kinda what ajax is suggesting and it’s not a bad idea at all, naturally it would require that we can get exact matches for decoding which on fast moving platforms can be hard.
Ajax’ suggestion does seem like the sanest suggestion and it avoids the overhead of running with debuginfo entirely as far as I can see.
Ubuntu has unfortunately decided that they will no longer support bug-buddy or gnome bug reporting. Instead they’re developing their own custom application to detect crashes in any application and send a core dump to their custom server to extract debug code. They’ll then modify thier proprietary launchpad bug tracking system to deal with these, in a similar way to gnome bugzilla, but obviously not quite as good.
Reasons I’ve seen for not using bug-buddy are that the user interface isn’t good enough and that it is too gnome-specific. I’ve seen nothing to suggest that their application is any better.
Sounds like a great idea, I’ll try to add a gnome-dbg metapackage that pulls all GNOME debugging packages that are available.
The nice things about installing a limited selection of debug packages at intall time are:
– requires no new infrastructure
– requires no time commitment from busy developers
– end users not required to learn anything new
– end users feel like they’re contributing by opting in
– can be done today
The number of bugs reported for the top 5 (buggiest :-) Gnome apps by far outway the number of bugs reported for all others.
Installing debug packages at install time for nautilus, evolution, totem and epiphany plus gtk, glib and pango is an achievable 80% solution.
(btw. installing *all* debug packages may be just too much to ask of the end user and may not actually help the situation).
While FC7 and Fiesty are giving pretty solid debug feedback for the next 6 months, we can work on version 2 — debug symbol resolution on the server for all packages.
For help with version 2, see:
http://google-code-updates.blogspot.com/2006/12/programs-crashing-airbag-helps-you_21.html
thanks a lot everybody for the feedback, here and by private email!
i will come back to this in 2007 and hope to get some kind of round table to make some progress here, but now it’s time for holidays and a well deserved “offline” vacation. :-)
(for those celebrating it,) have a nice christmas,
cheers,
andre