andré klapper's blog.

evolution

at the beginning of the 2.23 cycle, i want to take a look at evolution’s user-visible messages. a lot of non-crasher bug reports (and especially support questions in forums) deal with error strings that are hard to understand for average users. i filed an evolution tracking bug to collect bug reports based on cryptic messages. in a kind of way “evolve your user interface to educate your users“, though you of course cannot compare the information that can be displayed on a 1024x680px webpage to a small error popup.
this should also include error messages that are useless to the user, e.g. the famous (and now fixed) bug 213072:

it does not totally fit here because it is about security and phishing, but i love the Phishing Tips and Techniques somebody linked on planet gnome a while ago. it tells a lot about application dialog design and its effect on users’ behaviour.
so my task currently sounds like going through evolution’s error messages xml files and see what can be improved. any additional comments to bug 502515 appreciated.

translations

at the beginning of 2.23 gnome should migrate from using context for strings to msgctxt which is less error-prone and supported by most translation tools. see http://live.gnome.org/GnomeGoals/MsgctxtMigration. i also hope to push other gnome goals and the migration from deprecated modules like gnome-vfs and libgnomeprint*. let’s get a platform that is attractive to vendors and contributors.

marketing

for the second half of this year, i would like to concentrate a bit on FLOSS marketing. which projects have good marketing, and what can be improved? i hope that this will lead to become my diploma thesis. firefox and gnome are of potential interest here, though they have quite different target groups.

• GHOP tasks: so far we have at least 59 fixed bugs by GHOP students (in fact it’s much more, but i’m too lazy to tag them in bugzilla). congratulations to all participating students and their mentors!
  a few maintainers have been very active adding tasks (i’d especially like to thank the people behind gthumb, deskbar-applet, totem, online-desktop, anjuta and a few more projects for adding tasks), but most folks i talked to said “naah, no time”. can understand that – mentoring a student takes time, but some of our GHOP students are definitely interested in long-term contributing. and some of those students that cannot find a task because no unclaimed tasks exist are probably also interested in long-term contributing, but we lose these opportunities.
• GNOME Goals: same here, there’s no momentum to get that stuff worked out… the PoLinguas goal is only waiting for the non-answering gparted maintainer to review (the rest of the modules is harder to work out), and the PoptGOption goal is only waiting for patches for Evolution, bonoboui and gnome-python and the unresponsive gnopernicus folks. i’m sometimes impressed by the ignorance even of maintainers of small modules that it takes years and several pings to get such simple patches in. maintainers may say “naah, no time, more important stuff to work on”. can understand – small goals also take time. i just wonder how attractive the GNOME platform can be towards contributors or potential investors if you don’t clean up your codebase. i’m curious how long it will take until we can finally stop to ship deprecated gnome-vfs and libgnomeprint*. probably ages.
• release notes: we had bad press for 2.18, and we had bad release notes. we had good press for 2.20, and we had good release notes. surprise? the earlier you start working on cute release notes, the better the text and the (number of) screenshots can be. you need input from the maintainers for that, and nagging every single maintainer takes time. GNOME has a roadmap for that, and the maintainers shall update it with the module features and also plans for 2.24, now that we have reached 2.22 feature freeze. some maintainers will say “naah, no time”. can understand – refelecting on the important stuff you’ve added in the past months takes time. but the release notes are the most crucial thing GNOME has to manage in six months. if the notes suck, then the GNOME release will suck (at least according to the press). journalists will not just wait to see for themselves and spend their time on running 2.22 to write an article about it two weeks after everybody else has written about it. and don’t even mention sneak previews that we don’t have the volunteers for.

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. ;-)