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