andre klapper’s blog.

Haven’t seen much blogging about the Mozilla/Maemo Danish Weekend yet - here we go.

After meeting at the airport with Lauri Võsandi (who works on Bittorrent support in Canola as part of Google’s Summer of Code) and quickly getting a shower in the hotel, we went to the café of the IT University (the host of this event). Nice to see some familiar faces again plus those that you have only seen pictures of before. That evening I mostly had discussions about technology and politics (hey, there were also “real” Danish students around and not only Mozilla or Maemo hackers - there seems to be a life out there!).

Saturday was opened by Mozilla’s William and Nokia’s Quim in the one lecture room that we had. Many people though also spent their time in the large hall room (lovely architecture!) for sitting, hacking and discussing together. There were talks about Fennec (Mozilla’s browser for smaller devices), Canola, Fremantle Stars and Mer.

Coffee, tea, great sandwiches for lunch and sweets for the afternoon were provided (though the coffee was removed one hour before lunch - this decreased productivity for many people).

In the evening after picking up some All you can eat we met in a bar in the center to have some beers.

On Sunday we had about 25 quick lightning talks, sometimes just a few words explaining “I work on/I can help you with…” but very helpful. It was also a pleasure to talk to some Mozilla folks that were curious about how it is to deal with a big company that (slowly) moves to Open Source.

All in all, a very good and helpful weekend.

Work related on that weekend I introduced an “upstream” keyword in maemo.org Bugzilla (had that in mind for some time now), discussed the clutter blocker with Niels and Soumya, fixed some database sanity check issues, triaged lots of bugs, and started to concentrate more in triaging bugs & feature requests for Fremantle. So if you are subscribed/have voted for requests that interest you you might have received some “Fixed in Fremantle” bugmail but especially for feature requests I have often set the Version field to Fremantle which basically means “This is not fixed yet”.

Still thinking about how to deal with bug reports about API documentation (which is directly handled by the corresponding package developers and not by the Documentation folks) - I more and more tend to add a “docs” keyword and to keep those bugs in the corresponding (code) product instead of moving them to the “Developer Platform > Documentation” product so they remain visible for the developers. Comments?

Looking forward to the soon-to-come maemo.org Brainstorm for feature requests that deal with a broader scope.

How up to date are the bug reports?

There’s currently only 5 open non-moreinfo Apps/Platform tickets left with version field set to a version earlier than 4.0.
That’s quite cool because it means that there’s nearly no non-updated bugs left about Bora or earlier - stuff that’s not being worked on anymore anyway. Having an up-to-date bug database is important to see what issues are still relevant, so help is welcome to check whether tickets filed against Chinook still apply to the latest Diablo version (5.2008.43-7) by simply adding a comment and updating the version field.
But even more helpful is to check if tickets still apply to Fremantle. This can be done for some Platform issues by using the Fremantle SDK alpha.
There’s currently 38 open Platform tickets with the version field set to Fremantle, but this also means that there’s 267 open Platform tickets with version field not set to Fremantle.
The maemo.org Bugsquad is waiting for you - even if it’s only one small bug that you check, it definitely helps improving the platform and is appreciated!

Fremantle SDK alpha

Very late to blog about this, but some people might have seen that I’ve created a few more Target Milestones (5.0-alpha, 5.0pre-alpha) instead of the generic “Fremantle” one when the Alpha SDK was released. This should make everything a bit more transparent by having exacter information on when a bug was exactly fixed.

Explaining how to Vote for a bug report, as I’ve read a few complaints in ITt and in private mail.
Voting is helpful to identify the main issues that the Internet Tablet users and maemo.org community members have.

Log in to maemo.org Bugzilla and go to your favourite enhancement request or bug report. For this example I’ve chosen bug 1693.

Click on “Vote for this bug”.
This will bring up a page displaying all of your votes. Now enable the checkbox next to “Enter New Vote here” and click on “Change My Votes”.
That’s all. Of course you can also change your existing votes.

Yes, also from my point of view the User Interface is a bit confusing, hence blogging about this.
For a related discussion on how to handle feature requests see the ITt thread.

Every component in Bugzilla has a default QA contact (a virtual email address with the suffix @maemo.bugs, not completely implemented for Website bugs though, but finished for software bugs). To find the corresponding address for a component, go to the overview page, click on a product, and get the list of its components and its Default QA contacts.

Yesterday and today I fixed the mail settings for these virtual accounts (about 80% of these accounts had mail delivery completely deactivated). Now any changes to a bug report in component X will always send an email to X’s Default QA contact, now for all the software components we manage in maemo.org Bugzilla.

Why is that useful?

Because it makes it easy to watch bug reports in components that you are interested in, e.g. if you are a developer or a triager.
Log in to Maemo Bugzilla, go to your Mail Preferences, scroll down to “User Watching”, and add the Default QA contact’s email address to your watchlist. Now you will receive all bugmail about all changes to any reports of a specific component.

While doing this, I’ve seen that some folks were and are subscribed to QA contacts that had mail delivery deactivated. This means that a few community members and Nokians will suddenly receive a lot more bugmail than before, and maybe about components they are not interested in anymore. To fix this it’s the same as above: Edit your Watchlist and remove the stuff you are not interested in. Nevertheless expecting a few complaints on Monday when checking my mailbox (I’m off for this Friday).

Enjoy.

I’ve spent this Saturday on reorganizing the structure in Maemo Bugzilla (this was planned for several weeks). From my point of view, it will make it much easier to add future components/products without cluttering too much. For interested Nokia developers, it should be easier to track bugs (by e.g. adding the virtual QA contact to one’s email watchlist) because the new components fit better to the working areas of internal software teams. For the reporter, it’s hopefully easier because we e.g. gave the Home applets and the Utilities explicitly their own components.
Making it easier both for bug reporters to find the right product/component and for developers to track their components is like trying to square the circle, but I think we have a good compromise here.
I’ve also introduced a category named “X-Graveyard” which includes the “product” “X-Discontinued”. Stuff that is not shipped/not worked on anymore will end up here - less clutter in queries and products.

General progress

The decreasing numbers in Stephen’s weekly Bug Jars have already shown the nice progress we’ve been making in cleaning up two years of mostly ignored bug reports, though I must admit that a good part of the reports that were closed are either unfortunately “WONTFIX” or “FIXED for Fremantle, but not in Diablo”. This is not the perfect solution from a Diablo user point of view (and has led to some discussions and complaints), but I prefer to honestly forward this Nokia feedback (and receive some flames, though I’m not the one making these decisions actually) instead of continuing to just ignore the reports. You too, probably.

As you know I forward “valuable” reports (good steps to reproduce, tested with the latest public version) to Nokia’s internal bug tracking system, hence it’s interesting for me to see how many reports exist that do not have an internal reference yet. (Development platform bugs are handled in Maemo Bugzilla only so they don’t count here.) You can help reducing that number by taking a bug report that does not have an internal reference yet, reproducing it with the latest version and adding a comment about this. Even if it’s only one bug - it helps improving Maemo.