Andre is one of two Bugmasters responsible for the Maemo platform bugzilla. He faithfully wades through all the bug reports, comments, and votes that are filed daily on bugs.maemo.org. The end result of that effort is an Internet Tablet community which continues to have a feature rich and reliable device in its hands.
I'm sure that everyone reading this would love to have a few minutes of Andre's time. I consider myself fortunate to have him agree to do the following Q&A:
1. You were recently appointed as one of two maemo.org bugmasters. What exactly do you and Karsten Bräckelmann do on a daily basis as bugmasters?
The job description vaguely says "Administration of the database and communication with users and developers". This covers triaging the reports (reproducing them, asking for more information if required, cleaning up old reports), "educating" users to file good reports, forwarding "valuable" issues to Nokia's internal bugtracker and keeping it in sync (that's not a long term solution but right now it's due to Nokia's current workflow), Bugzilla maintenance (repetitive stuff like adding versions or target milestones), setting up the Bugsquad and guidelines for people interested in helping, and collecting technical knowledge from developers commenting on bug reports that miss information.
I think that covers most of what I'm doing. Of course I also try to follow up discussions on mailing lists and the Internet Tablet Talk forum to streamline issues and get them properly filed in Bugzilla.
2. Is bugmastery a full-time job, or do you fit it in between other activities that you have? Are you considered an employee of Nokia/Maemo?
The job position was created in May 2008 and is a full-time position. Karsten Bräckelmann and me shared the position for the first months (each of us working part time), but since I started full time in October Karsten has become the bugmaster in Nokia's Desktop Team and does not spend much time on maemo.org Bugzilla currently. He still helps me with technical issues (and might be back in a few months).
The job position is sponsored by Nokia, but I decide myself what is important and what I work on, so it is completely independent. I was explicitly told that I'm free to disagree and ignore anything Nokia comes up with (but that hasn't happened yet, I prefer to convince people instead). ;-)
I consider myself an employee of the maemo.org community because they basically decide what I'm doing (and if I'm doing it well or not), and of course of Openismus because they pay me and are a great company to work for.
3. Many tablet users out there do not participate in bugzilla. I for one, only started a few months ago. Can you give us an overview of the process that a bug report takes internally on its road to being dispositioned as fixed, and what groups within Nokia/Maemo are typically involved?
When a bug report gets filed the first thing to be done by the Bugsquad is to check whether enough information has been submitted and whether it can be reproduced. This might require providing instructions to the reporter to come up with some application specific information (for example creating a log file if the email application cannot connect to the server). When the report is in a good shape I forward it to Nokia's internal bug tracker (as already said, that is the current workflow and I'm the bottleneck, like it or not) and keep both reports in sync when new comments get added. When a bug gets fixed in the codebase, I also close the public bug report and add a comment about the version that will include the fix and its weekly build number. This is often a bit confusing as the fix is not immediately available for public, and we all have to wait for Nokia pushing a public SSU update (honestly, I also don't know about any release dates - that's unfortunately Nokia's current policy).
That's the normal process for software bugs. Development platform or Website bugs are directly handled in Maemo Bugzilla only.
4. Are there any common mistakes made when users file bugs that makes your lives difficult as bugmasters? Something that reporters/voters should do differently?
Reporters using the bug template and being as exact as possible already help a lot, because it saves time that is otherwise required to ask for more information. Imagine tracking down a short and simple "Can't send mail, please help" report and the follow-ups required to find out
whether it's really a bug or just a misconfiguration. The more valuable information, the better. If reports are vague in general I link against https://bugs.maemo.org/page.
5. Has any thought been given to providing some sort of dummy-proof way of getting a device's log info appropriate to a particular bug uploaded onto the bug report? What I envision is a bug reporting client on the tablet that you can invoke after you experience a bug. It would take a snapshot of the logs and/or device configuration and upload them to the bug report. Reporting bugs would become easier for the casual user, but may be a headache to implement, and also to manage on your end.
Nokia has announced a Crash reporter at Maemo Summit. As far as I know it will be available for download from the SDK tools repository.
From my point of view and the experience in GNOME Bugzilla offering such a functionality for non-crashers will likely cause problems and noise, because bug reports will mix up with support requests that better fit into forums or mailing lists.
6. There has been some disgruntlement in the community regarding the lack of frequent OS bug fixes via the SSU. Is there a triage system in place that relates the severity of the bug to the frequency of an update via the SSU? For instance, one critical bug may generate an SSU to rollout a critical fix, but every 10 normal priority bugs will be rolled up in a separate update via SSU. Or is it a looser management system?
Uh, that question relates to Nokia's internal policies when to ship an SSU update, and I simply don't know of Nokia's release management's guidelines here. I assume that a high number of critical issues or even blockers will increase pressure to push an SSU update soon, but I think we all agree that we would like to see Nokia publish updates much more often than they currently do.
7. It seems to me that we are approaching a point in time where a monumental division in the community will occur. This is the creation of community developed/modified Maemo distributions (e.g. Mer) versus the officially supplied versions. Since maemo.org is supposed to be a community site, will bugs.maemo.org handle both, or just the official versions?
We already have a few community projects in the "Extras" classification in maemo.org Bugzilla (Canola, Community Kernels etc.).
In the long run, we want to make Bugzilla the home for every community project maintainer who is interested. However, to lower the amount of administration (creating components, versions and target milestones for each product) this requires some non-trivial code work first that unfortunately will not happen that soon, so I currently prefer to only have some outstanding community software hosted. Some community members already have permissions to set up new products in Bugzilla.
If the Mer maintainers are interested they are of course highly welcome!
8. There is a 'Fixed in Fremantle' discussion going on over at InternetTabletTalk. It has been pretty fiery over there. I know that one of the valid points users have made is that a bug logged against Diablo should not be closed as Fixed, unless it is fixed in Diablo. Obviously, each OS iteration has a finite life that is dictated by Nokia's business strategy, so the 'Fixed in Fremantle' logic can make sense from a corporate viewpoint. What do you think of this issue and the community's concerns? Are they founded, or is there fear mongering occurring due to a lack of understanding of things that will transpire?
I can totally understand the complaints from my user point of view, but it's simply the life cycle of a bug. Having a patch committed to the codebase ("RESOLVED FIXED") is something different than having the fix available for public and verified ("CLOSED FIXED"). Some issues are much easier to fix in the Fremantle architecture and backporting them to Diablo would create a lot of additional work, and Nokia is still a company that is interested in selling products and does not have unlimited resources and manpower, hence they concentrate on Fremantle and put less efforts in Diablo as time passes by. This is exactly where the community can fill the gap by picking up the code and continuing to hack and improve it, and Mer is the right direction to kick this off in an organized kind of way.
9. Stephen Gadsby over at ITT does a bang-up job of providing a weekly bug jar in his blog. Do you feel any pressure from this since the bug status is on the loudspeaker each week, or do you take it in stride as an interested community keeping a check on your activities?
It's not only my activities, it's the entire Bugsquad, other community members and Nokia employees that are involved too.
Stephen's weekly bug jar has been very helpful to me to see the progress we make and to identify issues. It's definitely motivating to see the number of open bug reports and enhancement requests decreasing in the last weeks. I would call it a kind of "positive pressure".
10. Anything last minute to say to the community regarding bugs or anything else going on at maemo.org?
Get involved! :-)
Report issues, triage bug reports - even testing one bug a day (if it's reproducible in the latest public software version) is already a big help. If you want to get started check out https://wiki.maemo.org/
'Post' Mortem by EIPI
Thanks Andre for providing some insight into the bugzilla process, and for the valuable discussion.
As can be seen, the maemo.org Bugzilla is THE PLACE to work within to have your frustrations with the platform officially heard and dealt with. Many users do this on Internet Tablet Talk, which provides alot of entertaining discussion, but does nothing (unless Andre happens to hear you there) to fix problems for you or anyone else.
Hopefully users will hop onto bugs.maemo.org to file bugs, vote for bugs, or even become a member of the Bugsquad (I didn't even know we had one!).
EIPI
Posts
3 comments:
Post-"Post Mortem"
At the time I sent Andre the interview, I did not realize that Karsten Bräckelmann had moved onto another position at Nokia. Currently, Andre Klapper is our sole Bugmaster.
Hello EIPI,
I love your interviews.... keep up the good work.
You only did not know about Karsten because he is way too lazy to blog. :-P
& Thanks again for the interview!
Post a Comment