andre klapper’s blog.

The Maemo Bugzilla scope

Currently Maemo Bugzilla is used as a bug tracking system for the “core” software elements shipped in the Maemo platform (to define the term “Maemo” itself, please see this discussion). This includes both Open source and Closed source components preinstalled on the devices by Nokia. Obviously this does not include stuff like Skype or Rhapsody - they have their own bugtrackers.

And there is Garage Tracker. It is the bugtracking system for all those products based on the Maemo stack, but not preinstalled on the devices by Nokia.

In my opinion and in the long run, Garage tracker should die. Maemo Bugzilla shall be the main bugtracking place for all products based on the Maemo stack. I just didn’t like working in Garage Tracker (have to admit that I just took some quick looks to synchronize the status of reports that were duplicated in Maemo Bugzilla). It reminded me a lot of that awful bug tracker that Sourceforge provided when I had a small software project hosted over there, but it may be only my personal opinion that Bugzilla is easier and better to handle than Tracker is.

So I wonder: Are Garage project maintainers happy with Garage tracker?
Would they be interested to track their bugs in Maemo Bugzilla instead? My (not even reasonible or founded) dislike of the Garage Tracker is entirely my personal opinion after working with several bug trackers in the past. I want your opinions - It does not make sense to think about this too much if everybody is fine with Garage Tracker.

And which projects should be handled in Maemo Bugzilla? Keep it in the current state, as described at the beginning? Open it up for everybody interested in using Maemo Bugzilla to keep track of issues in his/her Maemo based software?

The latter one would bring up the next question that Quim raised in the famous bug 630: Are then the apps preinstalled in a device, »maemo compatible applications«, a different layer sitting on top of the maemo software platform? Stuff to think about…

(Also posted this to Internettablettalk.com and to the Maemo-developers mailing list. Let’s see if I can manage to streamline the feedback. )

General stuff

Besides reading and triaging the new incoming bug reports, I have spent the last days/weeks cleaning up the bug database. I’m done with bugs with high priority and critical severity set, currently I take a look at any non-enhancement bugs, especially old bugs (this means: trying to reproduce it myself, querying for internal tickets, or asking if this is still an issue).
But now that Diablo is out I expect more incoming bug reports than the approx. 30 reports per week that we had for the last months. Give us your Diablo feedback!

Less incoming bug reports.

In 2008 (the last 163 days), 31231 reports have been opened and 29997 reports have been closed in GNOME bugzilla so far.

	2008 (accumulated)	2007	2006	2005
Opened:	70126	114043	67543	37845
Closed:	67355	108807	59006	34196

This means that for the first time we get significantly less reports than the year before. How comes? GNOME less buggy, less users? Probably not.

We have many crasher reports going by default to crash.gnome.org instead of GNOME bugzilla. This is a Google Airbag installation that is already in use and receives hundreds of bug reports, and no-one cares about because it is unusable, missing debug info for nearly every distribution on this world, and pretty unmaintained. I’ve asked for documentation a few times before GNOME 2.22.0 was released, but nothing has happened. There is no possibility for distributions to submit debug info to extract useful stacktraces. Only advantage I currently see is that we are not flooded by bugs anymore in GNOME Bugzilla, but we’re losing track on those issues that really count, because we cannot see the stats and numbers of the issues filed to crash.gnome.org - it’s a big black hole and some bugs there already have hundreds (thousands?) of duplicates.

Another potential reason for less reports: A long time ago, Ubuntu has switched to report by default to Launchpad instead, but now that Bugzilla automatically rejects incoming reports from old releases (=< 2.19.99) this finally makes a difference.
And all this means…? More spare time for bugsquaders! Code! Hobbies! Love! Ice cream! Real life, here I come!

Gimmie bugs.

GNOME Bugzilla continues to get flooded by Gimmie crasher reports (especially bug 475020, we can auto-reject most of the Gimmie problems but not this one) that haven’t been fixed for months.

And now I realize (thanks to cosimoc!): “After a talk with Gimmie creator Alex Graveley, due to his shortage on time to maintain Gimmie, he allowed me to fork Gimmie thus starting MAYANNA.” and “to not ruin the Gimmie name we decided to branch it. Alex is also a Project member of MAYANNA”. Can somebody explain to me why just branching Gimmie was not an option? So one avoids ruining a software project’s name by completely abandoning any development and progress on it? (Keep in mind: Gimmie [applet] was proposed for GNOME 2.22 by its maintainer.)
A fork makes sense if several people cannot agree on aims. But I don’t understand it if the main project seems to be dead anyway.
The first thing that translation team maintainers is told is to resign when it is time. I originally had this in mind, but maybe this cannot not be applied to a maintainer that has written the entire software project on his own, like in this case. So, can we call Gimmie officially unmaintained and dead? If so, we may warn translators to not waste their time, and we may auto-reject any Gimmie bug reports in GNOME Bugzilla and close all existing bugs as WONTFIX. Currently it’s just the feeling of wasting time to see people triaging all those incoming Gimmie duplicates but nobody cares about the reports, that’s why I blogged this.

Time to finally blog about what Karsten and me have been doing for the last weeks in Maemo Bugzilla. Karsten has been mostly looking at the infrastructure and code side to improve a few things and will blog about it once we have some results ported from the test installation to our work installation. In general we have to give Kudos to the hackers of GNOME Bugzilla that we were used to work with - it has nice convenience and statistics features (though everything can always be improved of course) and we want to port a few of them.

I myself have spent most of the time cleaning up bugs. This includes syncing the status of reports that have been duplicated to Garage tracker and Nokia’s internal bug tracking system, reassigning reports of people that have left or moved on to other fields, nagging and setting NEEDINFO state (well - “moreinfo” keyword in fact) on bugs that need more information from the reporter, and correcting priority and severity of crasher reports.

In the past, Maemo Bugzilla hasn’t received a lot of attention. Important, non-enhancement requests have sometimes been copied to the internal bug tracking system and been handled other there. To get a first impression on the existing criticism it was useful to read some rants and complaints (this may sound negative, but most of it was quite constructive).

Nokia’s internal bug tracking system works fine for their workflows. Nokia has a great internal error management process (milestones, well defined testing processes, fine-grained statuses etc). Totally different from the anarchistic bunch of spare-time hippie bugtriagers we are at GNOME Bugzilla.
And it’s a bit different from the open source software workflows that we are used to because it’s not transparent to non-Nokians, but I also have to admit the fact that the Maemo platform is bound to hardware that is provided and sold by a company that runs a business and has competitors.
In the long run, we have to discuss coping with the reports in Maemo Bugzilla itself and to better integrate our users and reporters. Information flow with Maemo Bugzilla reporters has not worked out well in the past and has led to entropy.
It will be a challenge to get developers to input in Maemo Bugzilla, but we will refine and improve with some time and increase transparency (one item of our 100 Days Action Plan). This will not magically happen in just a few days. It will also require changing the way some developers are used to work. “The theory is known, the practice is not that simple to implement” (to quote Quim here), but I have the feeling that we are on a good way and that the Nokia people are definitely willing to improve the situation by accepting some changes.

Our next steps?

To come up with a Triage Guide, to continue cleaning up the bug database, to discuss and improve the communication with Nokia developers, and to make Maemo Bugzilla a nicer place.
For a complete list (also of other Maemo community heads’ tasks), see the Maemo Sprint page for June.

…and don’t forget to file bugs!

Spent the last week at the Ubuntu Developer Summit at Prague. It was a pleasure to meet and see lots of friends and new people from the Ubuntu and GNOME universe. Technically speaking lots of workshops were a bit to Ubuntu specific to me (I mostly attended QA and Mobile sessions but do not run Ubuntu myself), but I hope that I could provide useful input with regard to upstream collaboration. Physically meeting makes it definitely easier to discuss problems and impressions directly instead of using IRC and mailing lists - I had a few talks about Nokia/Maemo.org bug handling, GNOME release team issues (with Vincent and Olav), general community problems and GNOME Bugzilla bug triaging.

(Crossclub, October 2007.)

At the non-technical side, especially the last two evenings were great - I shamelessly convinced a few people to go to Crossclub on Thursday and it seems that the majority really enjoyed it. The party on friday evening was awesome - both the Ubuntu band and afterwards our beloved DJ Daniel Holbach with his furious drum’n'bass set!

The downside: My laptop (which is my work machine and has always been broken, but problems have become much worse in the last weeks) seldom worked and even refused to boot most of the times so I had to use my N810 very often. This meant that I could not really work at the same speed I’m used to. Got to buy a new laptop this week to get back with full force to work on triaging and fixing stuff in Maemo Bugzilla, at least I fixed the missing In-Reply-To header for Maemo bugmail so threading in your email client should work now (thanks Olav!).
The current Maemo bugzilla database is messy, so the short-term plan for the next days is to sync bug report statuses with (duplicated/transfered) Garage tracker and internal Nokia bug reports while guenther is mostly looking at some technical issues to improve workflow. We will also start posting weekly reports and enhance them as time goes by (feedback welcome, like always - use mail or irc).

As already announced by Murray, guenther and me have started working on maemo.org’s bug database.

A quick introduction for the maemo folks (most GNOME folks should know me already):
I started triaging Evolution bugs back in 2004 when Evolution was still handled in Ximian’s Bugzilla. Since that time I have never really stopped triaging GNOME bugs, though the plan for 2008 was (and still is) to pass the GNOME triaging crown to a worthy successor (Cosimo, Gianluca, this one goes out to you!). Being a member of the release-team i also regularly try to identify showstopper bugs for major releases.

So, what can the maemo community expect from us?
(Simplified description with marketing buzzwords included:) Our task will be to improve the bug workflow and communication between developers and users, so in the end everybody is hopefully happier and more productive.
Right now i’m in the early stage of getting an overview on maemo.org’s bug database and finding out which options/tools are available that i am used to work with (workflows that i can copy/adjust or workarounds to get the information i want to retrieve), to identify the biggest problems (this covers both code and communication), and to get in touch with the maemo community - send mail, ping me on IRC (andre in #maemo on freenode), or come around and have a drink when you’re in town!

lots of regions have special easter traditions, so does my hometown. one week before the easter weekend, six six foot tall wheels made of oak wood get thrown into the local river so that the wood is saturated with water and cannot easily burn. at easter sunday, the wheels are brought up to a hill (the so called “easter mountain”, years ago my grandfather did this job with his two horses) and the wheels get “filled” with some special straw. when it becomes dark, a cannon announces each wheel that gets ignited and then thrown down the hill.
it’s a heathenish-germanic custom based on some sun cult, but to combine it with christianity the bells of the churches ring when the wheels are rolling down the hill.
for better imagination: exciting video footage (by anna and cedric) from last year here (youtube) and boring footage (by /me of course) from this year here (ogg video).

I’m quite late with this, but I like to mention a few more students that participated in Google’s Highly Open Participation Contest. I’m pleased to post our unofficial “runner-ups” here:

Patrick Hulin (patrick.hulin)

The GNOME Project has selected Patrick Hulin as our Grand Prize Winner because of the quality and quantity of his contributions to the project. He worked on a varied set of tasks including documentation enhancements, performance contributions to GTK+, test coverage improvements in glib and cairo, porting baobab from gnome-vfs to gio, and bug fixing on several GNOME modules, especially Totem.

David Turner (Cillian64)

David took on a variety of tasks. He warmed up by working on some of our “choose the bugs yourself” tasks (fixing twelve mnemonic bugs and testing five patches from GNOME’s bugzilla) just to dive into the codebases of empathy (providing support for removing groups) and gThumb (preparing to remove the libexif library). He also vastly improved the scrolling support in Evince.
In addition to this, David updated the JHBuild moduleset schemas and the (now new and shiny) manual itself.
David already had open source development experience, as the developer of tuxcast, a command-line linux podcatcher.

Natan Yellin (aantny)

Natan wrote an article on GConf for the GNOME Journal (not yet released). He provided Drag-and-drop support for the Online Desktop file widget and a mail widget for the Online Desktop sidebar, fixed a Deskbar-Applet bug and also modified gThumb’s metadata handling and enhancing gThumb’s script definitions.
Natan is full of ideas and provided own proposals for potential tasks. He is especially interested in AWN (a dock-like bar) and currently thinks about creating a universal applets framework for GNOME.

Philipp Kerling (k.philipp)

Philipp added an LCOV code coverage suite to Pango and GTK+ to measure code coverage. He also contributed code to the GNOME online desktop module by providing an embedded workspace switcher widget and popouts for the Online Desktop file widget. He removed old icons from the gnome-desktop module that are now shipped in gnome-icon-theme and fixed four bugs in gnome-build.
Philipp has also contributed to GNOME’s German translation team.

---

In general, we again like to thank all the students participating. Many of our students went above and beyond what had been asked for by the task descriptions and were also available in our IRC channels to help each other. It was a great pleasure and wonderful experience to work with all of you - looking forward to seeing you around!

six months later… thanks to everybody who was involved in another nice release!

translations

adding “just one additional string” to a module two weeks before a major release does not sound bad at first sight. but keep in mind that most of the modules have about 20 completely translated po files. it means that 20 translation teams have to edit their po file again. don’t request string freeze breaks that late in the cycle unless you have a real reason to (security issue etc). a “nice to have” is definitely not enough!

showstoppers

our showstopper list has become smaller. beside those 4 crasher bugs that have been around for some time now, only the missing ftp backend for gvfs (Company seems to work on it) and the missing migration of trash from the old location to the new one (i hope vuntz takes a look at it) are left.
gicmo is working on finishing webdav support and the “network:” backend has been fixed this week by a. walton. and of course alex and cosimoc also work like mad on squashing bugs and getting things finalized for 2.22.0. (now i hope i did not forget anybody in my list.) if anybody has the feeling that a big blocker for 2.22 has not been addressed yet, raise your voice now!
this development cycle is a tough one for our translators (many late string changes because of finishing gvfs/gio/nautilus and a lot of new strings due to new modules). just wanted to say thanks to our translators. you really do an awesome job!

The Google Highly Open Participation Contest (GHOP) concluded a few days back. Google had invited 10 Open Source projects, GNOME being one of them, to set up a list of tasks for high school students.
GHOP was a great success and we had much more interested and motivated students than the approx. 100 tasks that GNOME offered (so if there’s a “next time” for this, GNOME will definitely need even more maintainers/mentors filing tasks).
Thanks to the students, GNOME has seen a lot of contributed code, improvements in automated testing, translation and documentation and many bug reports and fixes (the link is not a complete list).

Today Google published the names of the Grand Prize winners. Congratulations to GNOME’s Grand Prize winner Patrick Hulin and to the many, many other students for their great work! We hope that you gathered experience, had fun working in the GNOME community and that you will continue to contribute to GNOME and Open Source. See you around!