Archive for the ‘maemo’ Category

Nokia making it complicated

Wednesday, July 22nd, 2009

As Maemo 5 (Fremantle) gets closer I’m worried about

And the code of some modules in SVN is totally outdated though the recent code is available anyway in the Fremantle SDK releases.
Pushing this to SVN should take less than hour but some managers obviously don’t recognize that there are developers out there interested in the platform. Which is a pity.

Mozilla/Maemo Danish Weekend

Sunday, June 7th, 2009

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 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 Brainstorm for feature requests that deal with a broader scope.

Checking and updating old Maemo bug reports

Friday, March 27th, 2009

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

New year = Time for some Bugzilla stats.

Saturday, January 3rd, 2009 Bugzilla.

And GNOME Bugzilla.

Voting for reports in Bugzilla

Saturday, December 20th, 2008

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 community members have.

Log in to 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.

Watching products in Bugzilla

Thursday, December 18th, 2008

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 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. reorganization done.

Wednesday, December 10th, 2008

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. :-P

Stats showing the Clean up progress

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. Reorganization

Friday, November 7th, 2008

Product Reorganization

The current organization of Maemo Bugzilla has some flaws. I won’t repeat the reasons here, see for example the Getting Nokia involved in wikipage if interested.
Quim has come up with a helpful draft for reorganizing the products and components that has received several iterations now after integrating my own ideas and analyzing structures and components in both Maemo Bugzilla and Nokia’s internal bugtracker. In short: Split applications from the underlying platform, and getting prepared for where to add the new Fremantle products (like Meta Tracker or clutter).

Implementing this means to move a lot of components from A to B. This will trigger thousands of emails. While a few Maemo folks will hopefully send me some chocolate, most average people will hate me for spamming their mailboxes. So I prefer doing this on one day and completely disable sending Bugzilla mail (and probably add a warning banner one week in advance on every Bugzilla page).

I want to get this done before the Fremantle Alpha SDK gets released. Comments on the draft welcome.

Virtual QA Contacts

Bugzilla provides the concept of having QA Contacts and Default Assignees on a per-component level (components like Bluetooth are a sub-level of products like Connectivity are a sublevel of a categorization). QA Contacts and Default Assignees are just “users”, and every user in Bugzilla has an email address that does not need to be a valid one, let me explain:

If you are interested in getting all bugmail for a specific component, you subscribe to the email address of the particular QA Contact by adding it to your watchlist in your Email preferences in Maemo Bugzilla.

Currently there are lots of QA Contacts and Default Assignees ending with and some newer ones with @maemo.bugs.
Problem: email addresses exist in reality. It’s a bit unlikely that an individual will apply for the email address, but nevertheless it’s IMO bad to use an existing real domain.

Instead, I prefer to constantly use aliases with the non-existing top-level domain “.bugs” (like browser_bugs@maemo.bugs) – this is also what GNOME Bugzilla is doing by using a -maint@gnome.bugs suffix, and it has worked out quite well. (Another nice side effect of using alias is that you don’t have to reassign all bugs when a developer in a company moves on to maintain a different component – instead the former developer just removes the alias from his watchlist, and the new developer adds it to his watchlist. Less bugmail noise for everybody.)

So I’d like to harmonize this, one big problem though: Some of these addresses might exist in reality. If e.g. “” is a real user and not a virtual one, and I change this to “sdk_bugs@maemo.bugs”, will of course not receive any emails anymore. Need to take a look which of these users are correctly marked as inactive and probably check for the rest of them. :-(

Feature Jam (Go vote!)

Published a very first Feature Jar for the community and Nokia product managers one week ago. It’s rough and will soon receive another iteration. This is planned to happen monthly now. Keep in mind that Nokia handles feature requests differently from “real” bugs (other persons to contact), hence this is seperate from Bug Jars.

You can raise your voice by voting for existing bug reports and enhancement requests (much prefered to “I want this too” comments)! Every bug report has a “Vote for this bug” link. Use it! Also see the My Votes page for more information.

Cleaning up

I’ve also been spending some time on triaging dozens of old bugs (bugs, not enhancement requests) to continue cleaning up. There’s still enough reports that have never seen any comment added though, and sometimes I even have to close valid non-critical Diablo issues as WONTFIX because the issue will not exist in Fremantle anymore (radical code changes) and because the corresponding Nokia developer teams have already moved on to spend their time on Fremantle only except for critical issues. I always feel a bit sorry for this, but I understand that a company has to set priorities on where to use manpower and resources…

However, I think we’re on a good way – if you want to help, just pick up an old bug and try to reproduce it with the current Diablo. If it’s still an issue, update it by leaving a comment and setting the “Version” field to the version that you have used for testing. If you can’t reproduce, also add a comment telling us the version you’ve used and the steps you took to reproduce. Even if you only take a look at one bug, it’s an appreciated help! Also see the Bugsquad wiki page for more info in general.

Last week.

Tuesday, September 23rd, 2008


  • Finally been able to attend a concert of Vypsaná fixa at a festival. Feeling happy for the rest of the day (not only because of that one band).
  • Watched Prague’s local icehockey derby Slavia vs. Sparta (2:1). Could have been more exciting. Security checks like at an airport. Same as the food prices at the venue: Impressive, in a negative sense.
  • Bought two beers at night and gave one to the first person I met on the streets. Two street cleaners lucky about having a short break. Do that more often, it’s easy.
  • It’s that Burčák season again! Yummy.
  • Travelled to Maemo Summit with jbenc. One guy sitting next to us in the train heard that we were talking about linux and joined us. There’s really linux users out their in the wild, they exist, and they are not antisocial! :-P


  • Maemo Summit itself was awesome – most impressions have been already covered by the blog posts on Planet Maemo. Much more people than expected and a nice geeky venue. In general it also underlined my positive impression that Nokia’s opening and understanding Open Source better. My talk went well though there could have been more attendees. Most discussions (like always at conferences) happening outside of the talks or when having a beer at the evening, quite productive. Great Openismus party on Saturday, great company! ;-)


  • Now looking forward to the GNOME 2.24.0 release coming up this week. Hope we all (devs, translators, documentators, artists, bugsquadders and so on) did a good job and will get content users and good reviews.

Getting Nokia involved in Maemo Bugzilla?

Tuesday, September 2nd, 2008


Thanks to Nokia I had the opportunity to spend a few days at Helsinki last week, having talks, discussions and meetings with several people, especially in Maemo error management.

As I interact with Nokia’s error management by discussing/forwarding bug reports, and as there have been some confusion and misunderstandings already (Karsten‘s and my work do not fit perfectly into Nokia’s current well-defined and not easily to change workflows), I gave a small presentation about what we are doing, the problems and expectations.
I see ourselves (the bugmasters) as a kind of bridge between the Maemo community and Nokia’s product management. Being involved in Maemo and GNOME, we’re used to open source and understand its culture, but I can also understand managers being conservative when it comes to changes and when advantages aren’t obvious at first sight.
So at the beginning of my presentation I asked the audience (Nokians involved in error management) how many of them have ever dealt with open source community, culture and practices. It was less than 15%, something I had expected. My theory is that in general, professional error management in open source projects often simply does/did not exist, hence there can’t be that many people existing already used to it – definitely not Nokia’s “fault” or whatever. I explained that 3rd party developers, power users and fans can help any company leading an open source project in producing better software by helping in testing and providing patches and feedback, but they also have expectations and want to get something back for their efforts, e.g. becoming more involved and having more transparent processes. Or to quote a fine sentence by Jaffa that I also said while having my talk: “If Nokia aren’t seen to be committed to the community, why should the community be committed to Nokia?”
In my impression Nokia has already improved in understanding, but there’s still a long way to go. There have been “bad” examples, e.g. I was told that Nokia probably publishing updates more often now is already a sign of becoming more open (Sorry, this is an internal decision and has nothing to do with community involvement). But there also have been good examples. See, Nokia is a big company with lots of different opinions and people with different backgrounds and hence different definitions of “Openness”, and talking to each other helps to understand “the other point of view” better. Some Nokians involved in error management will be present at Maemo Summit. Looking forward to continuing discussions with community folks (and input) around.

A valid argument that I can second is that developers want to have one central place to track their bug reports. This is currently Nokia’s internal Bug tracking system. Some Nokia developers also comment in Maemo Bugzilla (mostly those coming from open source too, and in my impression this number has increased a bit in the last months), but quite often you don’t have the time to track two systems. Hence I waste spend a lot of time already on keeping reports in sync (been working lately on porting a script I use in GNOME Bugzilla to quickly insert comments on bug reports to save some time).
But I also do second that in the long run we should have those components that are completely open source in Maemo Bugzilla only. Now you might ask: Why not starting this immediately? So when examining on how hard it will be to open some parts of the existing internal infrastructure, I was often told that there are legal issues to resolve first. It’s not only about Nokia’s internal Bug tracking system, there’s much more that’s part of the long tail – information that a commercial company does not want to be accessed by its competitors, such as for example policy plans, product and hardware information, information about the internal testing infrastructure and especially copyright related issues. So it’s time to identify and check those blockers one by one. But there definitely IS slow change (maybe too slow for some Maemo folks that have been expecting more changes for the last two years), probably Nokia just needs more lawyers to handle all this more quickly. ;-) Bugzilla stuff

Apart from the ongoing triaging of new incoming bugs, syncing between the internal Bug tracker and Maemo Bugzilla and reorganizing some components in Maemo Bugzilla to fit better with Nokia’s internal development teams, we are going to remove the deprecated bug resolution RESOLVED LATER in the next two weeks. “LATER” either means WONTFIX, or the bug should just remain in open state. This requires “fixing” the existing bugs first. After that, LATER can be removed from the Bugzilla code. We have already removed the meaningless Target Milestone “Next” and retriaged all bugs RESOLVED REMIND that also needs to be removed from the code.
I have also disabled setting the Target milestone when filing a new bug, because Target Milestones are definitely not wishlists. Setting “Fremantle” or “Harmattan” as a target milestone for a bug should really mean that a developer works on it and plans to get the issue fixed by that release. We currently also discuss on switching to the “guided” bug entry template to make it easier to file valuable bug reports, but currently that template is way too crowded and noisy to be useful, so this will take some time and changes.