andre klapper’s blog.

Incoming reports in the last weeks

As I’m quite busy with the normal “Triaging and Syncing” business already (as seen above, a first increase of bug reports happened right after Maemo Summit in week 41, but I expect way busier times ahead) Karsten concentrates on technical stuff. It’s good to have him back as now stuff gets done that unfortunately was on the backburner.
First pay-offs (small, but definitely worth to mention, not only for the sake of transparency) that were done because I could “outsource” this to Karsten:

Entering a new report

Having users/customers reporting a bug in order to improve a product is great (always keep in mind that they do not need to spend the time on that). However the freetext input makes this sometimes complicated: A “Steps to reproduce: Connect to foo.” is vague when there are several ways offered by the UI to connect to foo and only one of these ways triggers the bug. Also, some testers (me, for example) love to simply follow braindead exact instructions without the need to think a lot.
Hence Bugzilla now asks reporters to use an ordered list to provide exact steps. Yes, it is helpful.
Also, when it comes to reproducibility of issues an answer like “Sometimes, but not too often” is always a bit vague and does not tell how often the reporter had tried (once? five times?). Now we ask for numbers like “maybe 3 out of 10 times”.

New “Moved to Brainstorm” answer

Closing valid enhancement requests as INVALID just because they are better suited for maemo.org Brainstorm always sounded a bit rude. We now have a MOVED resolution plus a nice one-click-button-and-done implemented.

And third, we have a link to the Bugsquad on the maemo.org Bugzilla frontpage now.

More news to come.

After spending three holidays in Amsterdam (rainy but still a wonderful time) we moved from our hotel to the Openismus apartment on the evening before the summit started. Great to see the friends/colleagues again, plus only 5 minutes of walking to the venue.

As my laptop had died directly after arriving in Amsterdam this was a good chance to test whether Modest is an acceptable replacement. I ran into three issues: Not possible to mark several messages at once as read, no threading view (really important if you get lots of Bugzilla mail and want to read the previous one), and no option to search for a message (and not just in the one message that you have selected).

Conference opening was nice. Jim Zemlin’s keynote (Linux Foundation) was a bit too much for me though, sounded like “Linux will have 101% market share next year because it’s better than everything”. Qole interviewing Ari Jaaksi had a good moment: Ari stated that having two bugtrackers does not make sense in the long run. Good to hear that common sense is shared.

I was content with my talk about the current situation of maemo.org bug management (boring slides here, video hopefully later).

Now that Nokia handed out 300 N900 pre-production devices to the folks at the summit, maemo.org Bugzilla has been flooded with new reports. Most of them have a good quality (seems like developers know that being exact in the initial description saves everybody’s time) but still it looks like more than we can currently perfectly(TM) handle so we need more help in the long run.
Let’s see how the next weeks go, especially when average users have found their way to maemo.org Bugzilla and start filing their issues. Keep in mind that for many it will be the first time to do this, hence let’s be friendly and explain some triaging decisions whenever it makes sense (”Thanks for reporting this. This has been already reported.” or “Thanks, but this is not a bug in the software itself. Please go to http://talk.maemo.org to receive help in this case.”).
As said, help is always welcome.

Photo by thp4, CC licensed

It’s the beginning of October and one year ago I started working fulltime as maemo.org Bugmaster (after I had started together with Karsten in May 2008).
Where are we and what are the plans?

Stats

On 29 Sep 2008 there were 1076 open tickets (including Website). Now there are 658 open tickets (including Websites, excluding Extras). That of course does not mean that difference of 418 tickets has all been FIXED (some reports became WONTFIX or got closed due to lack of response of the reporters when asking for more information), but it shows that there’s activity, feedback and that reporters can expect that somebody cares about their issue.

In the last 12 months 1501 reports have been filed (including 3rd party Extras apps, without it’s only 651). That’s normal average (10/2007–09/2008: 1690; 10/2006–09/2007: 1269). Curious what the number for the next 12 months will be though.

Nokia

What has only improved a bit is getting Nokia developers to work in the community instead of with the community. Big thanks to those trying it already.
It’s the Nokia management that has to allocate developers’ time for this, and it’s the community that has to convince with arguments why it’s better for everybody (simply imagine managers and developers used to commercial closed source development, e.g. the S60 series). I won’t elaborate in this paragraph; in short: I do hope to see improvement here after Fremantle (Maemo5) launch and by having some discussions at the upcoming Maemo Summit.

Misc

• We’ve opened Bugzilla to also provide bugtracking for some 3rd party applications hosted in the maemo.org Extras repository.
• At the end of last year the structure of the products and components was reorganized to better match user expectations (”Hmm, where should I file my issue?”) plus also the organization of internal Nokia developer teams. That was a bit like trying to square the circle but I think that the compromise is pretty good.
• Additional to Stephen’s awesome weekly Maemo Bug Jars I started providing a monthly Feature Jar that only covers the enhancement requests in Bugzilla, published on the maemo.org mailing lists and in talk.maemo.org. It’s based on the votes for each request, so if you have a application-specific wishlist item that is an affair of the heart to you go vote for it in Bugzilla (if it’s platform-wide it’s better suited to file it in the maemo.org Brainstorm).

Future

• Planning the changes required for Fremantle (adding new products, changing some descriptions etc) is basically finished. Next is to add all this and set it up once the final Fremantle version is available.
• Porting the Bugzilla codebase to upstream 3.4 version – ongoing (currently working on CSS). Ferenc has been a huge help codewise so far. I owe him quite some beers.
• Regular bugdays. See next paragraph.

Bugsquad

I’ve already blogged about changes and expectations related to the N900 launch. One more thing that I’d like to add: After the N900 launch I want to start having monthly bugdays – the maemo.org Bugsquad is a great way for people that want to get involved but don’t necessarily want or know how to code. Bugsquads constantly need fresh blood as they always tend to “lose” members to the evil, evil codewriters fraction.

You

So what are your impressions and expectations with regard to maemo.org Bugzilla?

(Picture by Dženan Šehić, CC licensed)

The Nokia N900 is more targeted to the mass market than any of the Nokia Internet Tablets before. This means that Maemo will see new users, with different levels of knowledge, and involvement.
Some will just use their device and will not be interested in contact with other users.
Some will ask questions on mailing lists or on maemo.org Talk (I myself started getting involved in Open Source by asking for a feature on a mailing list back in the days). As most people out there are used to Microsoft Windows this might also bring up some basic Linux questions.
Some people will file a feature request or bug report for their very first time as they have never used a bugtracker or brainstorm before, not knowing the difference between bugtrackers and support forums.
Some people will develop new software for the Maemo platform or port their application.

So, what can we do?

The maemo.org community should be welcoming by being helpful, friendly and patient. Open-source culture is different compared to “normal”, closed-source corporate companies, both in positive and negative terms.

Nokia should help making the Maemo platform successful by improving working in the community instead of just with the community.
Nokia developers should not only be allowed, but encouraged (keep in mind that many Nokia developers don’t have an open-source background) by their managers to spend a few minutes every day on the public mailing lists, in the maemo.org forum, in maemo.org Bugzilla.
At the beginning some might think that this is a waste of time, but sharing technical knowledge that Nokians have, plus talking directly to users and 3rd party developers is crucial for the success of the platform.
And Nokia should provide good public API documentation, of course – in the past, time for this has been missing sometimes due to tight schedules.

maemo.org is a nice vibrant community, ready to grow.
Maemo is a platform with great potential.

Let’s welcome new folks and give them a good reason to stay with us.

Photo credit: mcclouds (Creative Commons)

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

• Nokia implementing a buggy untested “3rd party policy” without having a dialog with the maemo.org community before. It was again the community running into problems and then finding out about it. Very annoying that Nokia does not learn to do better.
• Documentation for developers.
  • It is unclear which widgets support clutter.
  • It is unclear which widgets support rotation.
  • It’s not totally clear which widgets/widget properties support proper theming (a bit better now with this wikipage).

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.

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.