andre klapper’s blog.

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

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.

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.

Nokia

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

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

• The Maemo Bugsquad is now in place. For triagers we have a Triage guide, general and product generic Stock answers that can be copied & pasted into bug reports, and for reporters an updated (maemo’fied & and shortened) Bugwriting How-to. We also decided on a policy when to close rotting moreinfo bugs.
• There will be a Maemo Bugsquad BoF at the Maemo summit on Saturday, 16h30. Everybody also interested in managing the Maemo bugs is highly welcome.
• Being part of the current 100 Days plan, the Maemo crew has five sprints (and open IRC meetings too) à 20 days with defined tasks. For those who haven’t seen it yet, we also log our daily activities so our work becomes more transparent.
  As a first step to Get Nokia more involved into Maemo Bugzilla, I’m currently looking into Reorganizing components in Bugzilla to make it easier for Nokia’s developer teams to be able to track those reports that affect their scope.

The Maemo Bugzilla scope

Currently Maemo Bugzilla is used as a bug tracking system for the “core” software elements shipped in the Maemo platform (to define the term “Maemo” itself, please see this discussion). This includes both Open source and Closed source components preinstalled on the devices by Nokia. Obviously this does not include stuff like Skype or Rhapsody – they have their own bugtrackers.

And there is Garage Tracker. It is the bugtracking system for all those products based on the Maemo stack, but not preinstalled on the devices by Nokia.

In my opinion and in the long run, Garage tracker should die. Maemo Bugzilla shall be the main bugtracking place for all products based on the Maemo stack. I just didn’t like working in Garage Tracker (have to admit that I just took some quick looks to synchronize the status of reports that were duplicated in Maemo Bugzilla). It reminded me a lot of that awful bug tracker that Sourceforge provided when I had a small software project hosted over there, but it may be only my personal opinion that Bugzilla is easier and better to handle than Tracker is.

So I wonder: Are Garage project maintainers happy with Garage tracker?
Would they be interested to track their bugs in Maemo Bugzilla instead? My (not even reasonible or founded) dislike of the Garage Tracker is entirely my personal opinion after working with several bug trackers in the past. I want your opinions – It does not make sense to think about this too much if everybody is fine with Garage Tracker.

And which projects should be handled in Maemo Bugzilla? Keep it in the current state, as described at the beginning? Open it up for everybody interested in using Maemo Bugzilla to keep track of issues in his/her Maemo based software?

The latter one would bring up the next question that Quim raised in the famous bug 630: Are then the apps preinstalled in a device, »maemo compatible applications«, a different layer sitting on top of the maemo software platform? Stuff to think about…

(Also posted this to Internettablettalk.com and to the Maemo-developers mailing list. Let’s see if I can manage to streamline the feedback. )

General stuff

Besides reading and triaging the new incoming bug reports, I have spent the last days/weeks cleaning up the bug database. I’m done with bugs with high priority and critical severity set, currently I take a look at any non-enhancement bugs, especially old bugs (this means: trying to reproduce it myself, querying for internal tickets, or asking if this is still an issue).
But now that Diablo is out I expect more incoming bug reports than the approx. 30 reports per week that we had for the last months. Give us your Diablo feedback!

Time to finally blog about what Karsten and me have been doing for the last weeks in Maemo Bugzilla. Karsten has been mostly looking at the infrastructure and code side to improve a few things and will blog about it once we have some results ported from the test installation to our work installation. In general we have to give Kudos to the hackers of GNOME Bugzilla that we were used to work with – it has nice convenience and statistics features (though everything can always be improved of course) and we want to port a few of them.

I myself have spent most of the time cleaning up bugs. This includes syncing the status of reports that have been duplicated to Garage tracker and Nokia’s internal bug tracking system, reassigning reports of people that have left or moved on to other fields, nagging and setting NEEDINFO state (well – “moreinfo” keyword in fact) on bugs that need more information from the reporter, and correcting priority and severity of crasher reports.

In the past, Maemo Bugzilla hasn’t received a lot of attention. Important, non-enhancement requests have sometimes been copied to the internal bug tracking system and been handled other there. To get a first impression on the existing criticism it was useful to read some rants and complaints (this may sound negative, but most of it was quite constructive).

Nokia’s internal bug tracking system works fine for their workflows. Nokia has a great internal error management process (milestones, well defined testing processes, fine-grained statuses etc). Totally different from the anarchistic bunch of spare-time hippie bugtriagers we are at GNOME Bugzilla.
And it’s a bit different from the open source software workflows that we are used to because it’s not transparent to non-Nokians, but I also have to admit the fact that the Maemo platform is bound to hardware that is provided and sold by a company that runs a business and has competitors.
In the long run, we have to discuss coping with the reports in Maemo Bugzilla itself and to better integrate our users and reporters. Information flow with Maemo Bugzilla reporters has not worked out well in the past and has led to entropy.
It will be a challenge to get developers to input in Maemo Bugzilla, but we will refine and improve with some time and increase transparency (one item of our 100 Days Action Plan). This will not magically happen in just a few days. It will also require changing the way some developers are used to work. “The theory is known, the practice is not that simple to implement” (to quote Quim here), but I have the feeling that we are on a good way and that the Nokia people are definitely willing to improve the situation by accepting some changes.

Our next steps?

To come up with a Triage Guide, to continue cleaning up the bug database, to discuss and improve the communication with Nokia developers, and to make Maemo Bugzilla a nicer place.
For a complete list (also of other Maemo community heads’ tasks), see the Maemo Sprint page for June.

…and don’t forget to file bugs!