andré klapper's blog.

showstoppers.

the latest list of GNOME 2.22 showstoppers is out:

• Epiphany:
  • prompt service + tabs fix:accoding to chpe this is a must-fix for any release supporting xulrunner 1.9, so to be on the safe side this should get done for 2.22.
• Evolution
  • crash in camel_certdb_save at camel-certdb.c:371:
    142 dups total, 9 in the last 30 days.
    Crash when writing the certificates database. This seems to be not Fedora specific (see comment #119) and to still happen with 2.12 (comment #134), so it’s not Fedora-only. Any help to reproduce this (see comment 67 and 69 for flags) appreciated.
  • Error “Summary and folder mismatch, even after a sync”:
    87 dups total, 10 in the last 30 days.
    Sankar works on a workaround to silently resync the folder summary, without displaying a confusing error message to the user. this will hopefully be included in 2.21.90.
• Gnome-Panel
  • crash in gtk_rc_reset_styles() [2.18 only?]:
    866 dups total, all of them 2.18.
    Vincent said “it’s really unfixable if no developer can reproduce it”, so if anybody wants to help out, please provide the relevant SElinux log for vuntz, and the value of the gconf key /desktop/gnome/font_rendering.
• Gedit
  • crash trying to print [2.18 only?]:
    115 dups total, 6 in the last 30 days.
    There has not been a single 2.20 report so far, can anybody still reproduce this? Paolo said that they will try to migrate to gtk-print in time for 2.22 which would obsolete this bug.
• Gnome-Applet
  • crash in Battery Charge Monitor: Plugging in a USB mouse [2.18 only?]:
    80 dups total, 11 in the last 30 days.
    There has not been a single 2.20 report so far, can anybody still reproduce this?
  • crash in Volume Control: starting skype [2.18 only?]:
    286 dups total, 11 in the last 30 days.
    At a first glance it seems as there are only fedora7 (2.18) reports, can anybody reproduce this with another distribution than Fedora7? Comments 168 to 172 include some useful information.
• Gnome-Media
  • crash in Volume Control: changing settings [2.18 only?]:
    220 total, 55 in the last 30 days.
    Again, according to comment 216 this might be fixed in 2.20.
    Still missing a good stacktrace. Can anybody (preferably Fedora 7 users) reproduce this and provide a good stacktrace?
• Gtk+
  • Can’t click button after setting it sensitive:
    There are several reviewed and criticized patches attached. Cody recently commented the exact state of this and what has to be still worked out to provide the perfect(TM) patch. Help to get this in before GNOME 2.22 appreciated.
  • File save dialog deletes/empties filename when changing directory:
    In gtk+’s file chooser save dialog, the file name sometimes get deleted and must be manually entered which is quite annoying. This bug is not easily reproducible, but Olle Bergkvist investigated, created a testcase (comment 21) and plans to come up with a patch here.

another one i had forgotten to add to the original mail: crash.gnome.org. only fer can tell about its current status, but if we do not get this worked out for 2.22, i expect GNOME to lose feedback. some reports have already gone to c.g.o instead of bugzilla.gnome.org, but without having debug information of distros, c.g.o cannot decode the data.

stacktrace crasher bugs.

additionally, as we will get into more freezes, it makes sense to fix crashers.
there are currently 193 bugs with the keyword ‘STACKTRACE’ set (which means “decent stacktrace available) and with GNOME version 2.19-2.21 set (Bug list).
wanna hack? it lists bugs from anjuta, at-spi, bonobo, dasher, dia, eel, empathy, eog, epiphany, evince, evolution/e-d-s/e-exchange/gtkhtml, file-roller, gamin, gconf, gdm, glib, gnome-applets, gnome-control-center, gnome-media, gnome-mount, gnome-panel, gnome-power-manager, gnome-utils, gnome-vfs, gtk+, gvfs, nautilus, pango, rhythmbox, system-monitor, totem, tracker, vino, vte.
if only a few of these crashes get fixed, GNOME 2.22 users will have a more stable desktop and a better user experience. if the stacktrace is not enough information to get it fixed, add a comment and set the bug to needinfo. these are the reports that are useful for us, these are the reports from people that do have debug packages installed. i’d of course especially like to see contributions for those modules that lack manpower, like nautilus and gtk+. the end of a release cycle is always a good time to fix nasty crashers. get it stable!

one of the translation aims is to provide consistency of terminology. some translation teams have glossaries to achieve this (german, french, for examples). however, reality bites.
i’ve started to use the wonderful Open-Tran.eu project to search for inconsistencies – enter an english term and see the results from the po files of the different GNOME modules. the german po files have at least five different translations of “website”, and also inconsistent translations of strings like “page setup”, “scrollbar”, “mount”, “eject” or “select”, to mention a few i’ve searched for. perhaps other languages have a smaller variety of expressions that one can translate a string to, but i thought this information could be useful to share.

vincent already blogged about the Google Highly Open Participation Contest (GHOP).
it is a contest similar to google’s summer of code, but for high school students and with much smaller tasks in any fields like documentation, translation and code. the average amount of time to be spent for a task should be about three days.

we were overwhelmed by the number of interested students that want to contribute to GNOME, and many tickets have already been claimed and/or completed (the entire list of non-completed GNOME tasks is available here).
for example, some folks are working on nepali and romanian translation, fix some mnemonic bugs, or remember maintainers to update POTFILES.in when adding new tasks. nice side-effect: we now have patches for every module to complete the migration to the LINGUAS file, so maintainers please get those patches in!

if you are a gnome hacker, have an idea about a possible task, want to guide a student to fulfil it and perhaps also want to get new contributors for your project/area, propose new tasks and enlarge the GNOME community! because “we’re eager to see other people jumping in and have new task suggestions that we can approve.” yay!

• first of all: i’m probably the 26th person posting this, but: thanks a lot Nokia for providing me a discounted N810!
• found an old posting of dave and finally realized that the stuff on developer.gnome.org is located in the svn module “web-devel-2”. added a comment to the L10N Guidelines for Developers how to add translator comments to glade files and fixed the broken link to the documentation style guide (this has been brought up a few times on the gnome-doc-list).
• evolution is getting a lot of “can’t send mail. please help” bug reports, probably because filing a bug report is too easy – evolution has a “Submit Bug Report” item in the help menu (no other application that i know of has a similar menu item). getting tired of explaining reporters in bugzilla what support forums are, i wrote a quick and dirty patch to add an item linking to the evolution FAQ instead. now i only hope that people will not spam the wiki page with their unanswered configuration questions…
• played around a bit with GNOME bugzilla’s weekly-bug-summary.cgi.
  i took a look at the changes of the last 60 days per module in GNOME bugzilla. if you order by “opened in last 60 days” instead of “open bugs”, you will see which modules are triaging-intensive:

  Product	Opened in last 60 days	Total open bugs	Ratio
  Evolution	+4965	4333	1,15
  Nautilus	+2490	1427	1,74
  deskbar-applet	+1339	100	13,39
  epiphany	+903	382	2,36
  Rhythmbox	+867	635	1,37
  gnome-panel	+743	463	1,60
  gimmie	+690	110	6,27
  Gtk+	+254	1689	0,15

  (only products with more than 600 incoming reports in the last 60 days except gtk+, also note that these numbers do not include rejected bug reports).
  of course, the total number of open bugs is not significant at all, especially because this does not consider how many lines of code evolution and nautilus have. gtk+’s low ratio is probably because a lot of gtk+ crasher reports do not get correctly reassigned to gtk+ or lost/forgotten in bugzilla.
  so what’s interesting here? gimmie and deskbar-applet have a pretty high ratio. are products with a lot of incoming bug reports either popular or buggy apps (or both)? do important bugs get fixed very slowly and therefore produce a high number of duplicates, or should distros become better in shipping patches? *shrug*
  at least for gimmie one can see that it’s basically only two bug reports bringing all that noise.
  so in the end, i added a few reports to the auto-reject list (to hopefully reduce bugsquad’s workload), sometimes with a nice “it’s been fixed already, please file a bug against your favourite distro” auto-response. ;-)

at guadec, some people took a look over my shoulder to see me triaging (and Don told me about the correct pronounciation). of course the bugsquad sometimes teaches triaging to interested newbies in #bugs, but it was even more fun to explain stuff “in person” to muelli sitting next to me for example, or to discuss tips and tricks with other squadders (as long as claudio does not eat my cookies in the meantime, but of course he would never do). and people asked me to blog about it. now it’s october, and i’m late, but better than never:

a year ago i started to write a greasemonkey script that makes triaging faster in several points, and now i found time to clean up the code a bit (it’s still messy, but i never said that i wanna be a coder when i grow up ;-).
basic features:

• add a “stacktrace” anchor link to the top of the page so you can directly jump to the signal handler call by clicking only once, and then compare two traces by quickly switching between the two browser tabs:
• 
• add additional product- or distro-specific stock responses for some products that get a lot of reports, so it’s easier for reporters to install the right debug packages – for example, i also have “english, please!” or “this is not a support forum” stock responses for evolution bugs, because… i need them. sigh…:
• after clicking on the stock response, set keyboard focus to the “save changes” button to save the time you would need for scrolling otherwise
• reduce the width of the area containing the stock answer links. i have a big screen resolution and i like short ways

here you go for download (but be careful, it may eat your cat). feedback welcome, just send mail. (answers to possible questions: “i have only tested it in firefox, there will be problems with other browsers”, “no, the stacktrace anchor link cannot go upstream due to technical reasons”, “no, we don’t want individual answers for every single module and i don’t think it’s the way to go, it’s been just my personal workaround for some special cases and i thought it could be interesting for others too”.) thanks to nazgul for improvements and comments.

additionally, i have to say that having a laptop made triaging significantly faster for me too, because switching between keyboard and mouse on a desktop computer takes so much longer than using a touchpad and the keyboard which has only a few inches in-between them.
and i use keywords in firefox: you can open http://bugzilla.gnome.org/show_bug.cgi?id=100000 by entering “bug 100000” into the address bar, you only need a bookmark with the keyword “bug” and the address “http://bugzilla.gnome.org/show_bug.cgi?id=%s”. you can add keyword “q” to quickly get to the query page. and so on…

for the last months, the bugsquad started to add the STACKTRACE keyword to crasher reports with pretty perfect traces. useful evolution and nautilus reports should more or less be completely marked with that keyword now, so that hackers and contributors can find and fix crashers more easily. the keyword is especially useful for modules with a large income of reports and few developers/manpower, combining the querying with the latest version number. perhaps there’s some people around interested in marking good gtk+ crasher reports, and some other folks in fixing them?

i’ve added a few more resolved bugs to the auto-reject list so we get less dup reports. we still miss some information to track changes with regard to the number of rejected reports, so now that we reject reports from 2.16 distributions, i saved a copy of the auto-reject list to compare the numbers in a month, to find out which crashers don’t exist in >=2.18 anymore. easy one.

it’s amazing to see that we have a lot of bugsquadders currently (tom, susana, pedro, nazgul, bruno, diego, philip, muelli, cosimo, wolki and those that i’ve forgotten). i still wonder how we manage to create interest in this unpleasant repetitive gruntwork triaging work, but currently it looks like we’re successful in that. perhaps it’s time for me to look out for new challenges (and finish my studies to get a job). :-)