andré klapper's blog.

pretty busy with real-life stuff as i’m going to move, hope to find much more time in february.

there hasn’t been that much feedback on the GNOME 2.16.3 showstopper review, but since posting it, 349697 has been perhaps resolved and 353498 is most likely resolved.
however, there’s of course still a lot to fix to get GNOME 2.18 into a sane state. i’d really like to thank chpe for taking a look at the code and adding comments and ideas to some of the reports listed in the showstopper review, and would love to see more people taking a look at the current gnome blockers, because other people have other ideas, and because users are just happier if their desktops crash less often. ;-)

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?

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!

(welcome, dear planet gnome. who i am? check bugzilla, or the evolution archives.)

looks like luis was already scared by my previous chart, so here’s another one: the number of nautilus bugs filed per day, within the last months:


(yes, negative values are possible, because reports can be moved from nautilus to gnome-vfs, for example.)

just see how new releases of wide-spread distributions can ruin the sleep of the gnome bugsquad for weeks, and lead to burn-out at the end. more people triaging bugs could be the workaround, and more automation should be the long-term strategy.

played around with bugzilla.gnome.org’s reports.cgi and chart.cgi, and finally ended up in gnumeric. the chart should describe the situation pretty clearly – no more words, need sleep.

leaving evolution.

we’ve come a long way, baby…:

two weeks ago, i finally officially announced that i retire from being the evolution bug master, some weeks after already having retired internally. it really hurts to leave a project that you’re passionate about after several years.

for the reasons:
as time went by, involvement increased.
i once asked questions on the user mailing list, answered by rodo and guenther.
i didn’t unsubscribe and began answering trivial questions. looks like that in march 2004, i kicked off at the mailing list, and some people were happy when i finally became familiar with bugzilla.ximian.com (funny sidenote: i still haven’t read the triage guide yet) and started triaging on one of gerardo’s bug days, and it looks like i heavily cleaned up the evolution bug database by marking duplicates and closing obsolete reports. the amount of open reports decreased from 3000 to 2300 within a few months (no, that’s not all just because of me, of course). when i did not feel safe with a decision, i visited evolution’s irc channel just to drop in, ask questions to gerardo, and drop out (yes, please laugh at this behaviour now, but modem connections also mean losing money).
later, i began to write trivial string patches, test and review patches, discuss stuff with developers, developing the grand plan (TM), and attend the team meetings. after nags had left evolution, developers began to call me the bugmaster.

this was fun, a lot of work (read: time), and some responsibility. as everybody has to earn a living, i had a deal with novell for the last months to get paid for working half-time on evolution. beside that, i was asked to become a member of the gnome release-team, and elijah, vincent and luis convinced me of joining.
as a follow-up deal wasn’t offered, i had to look out for a new job (currently working at the university). release team, the general bugsquad work, earning a living and being the evolution bugmaster on a volunteer basis does not work out. yes, i still need time for living a life outside of the computer world, and i sometimes love being offline for a few days. therefore i had to make a decision – and swimming upstream looks more important.

with regard to evolution, i will go back to the start – by answering user questions.

though evolution has become much more stable within the last two years, imo it is in urgent need of a bugmaster (i doubt that general gnome triagers have enough knowledge for evolution-specific non-crasher reports, and i doubt that the evolution developers have enough time to answer user questions). perhaps, at some indefinite future date, i would return.
all my best wishes to the evolution project, and thanks for an awesome, great and sometimes stressful time, and for many new friends. i have learnt a lot about software project management, and i now hope that i can also improve the bugzilla situation for the entire project – GNOME.

into the void we have to travel…

1. add a “please write in english.” sentence. perhaps evey seventh or eighth bug report is not in english. i know some languages, but not all of them. please request a string and ui freeze so we get this in for GNOME 2.16.3, otherwise this will drive me (and the users who have to rewrite their entire report in english) nuts.
2. add a sentence that an account will be created and that the submitted email address will be visible for people that have logged in into our bug tracking system. just for privacy reasons.
3. the non-trivial one which was already covered by olav’s latest posting: make bug-buddy display feedback received from bugzilla.gnome.org. as the GNOME community and user base grows, we have to handle more and more reports, which either means that the bugsquad needs more volunteer triagers, or that we need more automation. the latter one should be the way to go. now imagine what will be possible by doing this: we can reject duplicates and tell the user about this, we can tell the user that his issue is fixed already and that his distribution provides an update, we can tell the user that he is using an obsolete version and directly reject the bug report. if every gnome bugzilla product has a boolean value providing its maintenance state, we can also tell the user that he/she should not expect fixes, as that product is currently unmaintained.
   we should also take care of i18n here by submitting the user’s LANG setting, so the feedback language can be adjusted.
   is anyone already planning this? bkor, fer? a must-have for 2.20, and a would-be-great for 2.18. thanks.