Archive for the ‘maemo’ Category

maemo.org Bugday: March 16th, 18:00-03:00 UTC.

Monday, March 8th, 2010

Announcing another maemo.org Bugday:

Tuesday, March 16th, 18:00-03:00 UTC
in #maemo-bugs on Freenode IRC

No specific topic set – see the wiki for some ideas.

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. Step by and say hello to the Bugsquad or become part of it. :-)

maemo.org: SNAFU ;-)

Monday, January 18th, 2010

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.

2009 Bugzilla statistics for maemo.org and GNOME

Friday, January 1st, 2010

This morning my calendar told me there’s a new year available, so I created some quick & dirty statistics for my favorite bug databases:

Maemo: Contributing and long-term platform strategy

Wednesday, December 9th, 2009

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:

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

maemo.org Bugday: Dec 15th, 18:00-03:00 UTC

Monday, December 7th, 2009

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

Tuesday, Dec 15th, 18:00-03:00 UTC
in #maemo-bugs on Freenode IRC

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.

maemo.org Bugzilla: Minor tweaks

Wednesday, November 18th, 2009
Statistics

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:

Screenshot

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

Screenshot

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.

Maemo Summit 2009

Sunday, October 18th, 2009

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

maemo.org Bugzilla: One year later.

Friday, October 2nd, 2009

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)

maemo.org: Welcome new users.

Monday, August 31st, 2009

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)

The N900 & Maemo 5

Thursday, August 27th, 2009



It’s announced.
And I’m proud to be part of it.
See it in action.