andré klapper's blog.

The last two weeks were a bit… stressful.

First of all some Nokia-internal changes with regard to Error Management, then maemo.org Bugzilla moving to a new server. Unexpected side effect was data loss. Spent part of last Monday restoring what I still had in my bugmail. Still it leads to confusion and mistrust (“Why was my account deleted?” – “You probably created it in that data loss time frame?” – “Ah.”).

Then we had the Maemo5 PR1.1 release on Thursday (with a nice ChangeLog) and some problems on Saturday and Sunday, hence bugmail (change notifications) was not delivered.

Sharing other thoughts on broader issues that are currently on my mind:

Before writing the very first bug report (maybe even of your life) it’s recommended that reporters take a look at the How-To. Good bug reports save everybody’s time and issues get fixed faster. We should put this information on the first Bugzilla page to avoid frustration on both sides.

Also the number of incoming reports is constantly high, hence I am sometimes short with my comments (as I also have to take a look at the internal comments for public tickets, verify some reported issues in newer internal versions, keep stuff in sync, and other stuff). Depending on cultural backgrounds some of my comments might be misinterpreted as unfriendlyness.

For the high workload Ubuntu has a nice approach called 5 A Day which is asking community members to triage five bug reports a day. I’d be happy with any number though. ;-)
On a related note, for some reasons I expect more Nokians to be around in maemo.org Bugzilla after the next feature release (PR1.2) has been published. Looking forward to it.

Another problem is that many normal users don’t understand the difference between a bug report and a forum (I’ve blogged about this before, anyway). That’s predictable if you’ve never seen a bugtracker before, but if everybody wants Nokia to be more present in maemo.org Bugzilla and folks actually reading bugmail and responding, please reduce adding comments on what is helpful and avoid unneeded fullquotes or answering above the quote.
Especially if instructions how to provide further information have been posted already adding just another “I have this problem too” comment is unhelpful and creates bugmail noise in everybody’s inbox. Bug reports with hundreds of comments, mixing up issues with similar outcome but different reasons quickly become unreadable so the same questions or comments get reposted plus subscribed people tend to ignore new comments. Of course this is also a question of providing better information on how to provide logs etc – should spend time on this in the next weeks.

In general of course reading before posting is required, but people are lazy. “If this is RESOLVED FIXED, then why do I still see that issue here?” It’s explained that FIXED does not mean PUBLISHED, but we could consider renaming FIXED after having Bugzilla 3.4 in place, as it confuses many people. Red Hat for example calls an internal fix “RESOLVED ON_QA” in their Bugzilla until the fix is really available for public.

So that’s the reason why I educate people ask people to please “behave”. Sometimes I scare some people or maybe have less friends at the end of the day, sometimes people are fine with what I’m doing.
In any way it’s necessary, I just felt a need to explain my intentions in public after a bit of negative feedback in the last days.

Great to see the interest on Maemo in the last weeks. As expected, traffic in the forum, in Bugzilla and in Brainstorm has increased impressively.
Discussions have been taking place (with regard to Bugzilla for example here or here) how to make infrastructure work out better for users, with some good proposals. I am also impressed by the patience and friendlyness towards new folks not searching for already existing threads or bug reports, partially pushing the limits of english grammar and punctuation, or towards folks having wrong expectations (Symbian is a completely different codebase than Maemo, hence talking about “regressions” is technically speaking wrong. If you want all of the Symbian functionality and lose some of the Maemo functionality, just get a Symbian device if it makes you happier). On a related note, I’m also trying to keep Bugzilla a technically focused place and make clear that it’s not a forum (“WTF???” comments are counterproductive noise if you want developers to read maemo.org Bugzilla mail, really).

Two issues that have been on my mind lately:

• I am afraid of Nokia doing the same mistake for Maemo5 that was done for Maemo4 – evolving and supporting a platform just for a few minor updates which is bad for the ecosystem around. “Maemo hasn’t had a chance yet to gain real long-term stability. The life-cycle of a Maemo version is too short for that, and there is no continuity between versions.” If 3rd party developers are unsure whether to write their new great application in GTK (abandoned for Maemo6) or Qt (not yet ready for Maemo5) they in doubt don’t write it at all and might support a different platform instead.
• Also, there must be improvements with regard to contributing (patches or even co-maintenance of modules). It’s too unclear where to find which codebase. Garage? Stage? Gitorious? Is it free or closed? Glad to know that Stskeeps is working on it as part of the maemo.org Sprints (ID: 9.11-04).

Open source community expectations are about taking (Give me the code!) but also about giving back (Let me provide patches in Bugzilla and have maintainers review them!).
Tarballs are available in the repositories, but hackers normally prefer the fresh code instead.

Photo by brentdanley, CC licensed

I’m proudly announcing the first maemo.org Bugday:

This is a nice way to get involved if you are a fan of the Maemo platform and the N900, but cannot or do not want to write code for example.

Bugdays are about hanging out together on IRC, triaging/discussing some reports in maemo.org Bugzilla, and introducing new people into triaging. No technical knowledge needed, no obligations. So, step by and say hello to the Bugsquad.

And now to some other bits and pieces:

• We’ve become stricter with regard to having non-trivial enhancement requests filed in Brainstorm instead of Bugzilla. To avoid reporter frustration, a note about Brainstorm when entering a bug report will be displayed in Bugzilla soon (Karsten is looking into this).
• New shiny Bugsquad logo by wazd (see above). Thanks!
• Published and updated version of my small maemo.org Greasemonkey triage helper script. Happy to share this.