Product Reorganization
The current organization of Maemo Bugzilla has some flaws. I won’t repeat the reasons here, see for example the Getting Nokia involved in bugs.maemo.org wikipage if interested.
Quim has come up with a helpful draft for reorganizing the products and components that has received several iterations now after integrating my own ideas and analyzing structures and components in both Maemo Bugzilla and Nokia’s internal bugtracker. In short: Split applications from the underlying platform, and getting prepared for where to add the new Fremantle products (like Meta Tracker or clutter).
Implementing this means to move a lot of components from A to B. This will trigger thousands of emails. While a few Maemo folks will hopefully send me some chocolate, most average people will hate me for spamming their mailboxes. So I prefer doing this on one day and completely disable sending Bugzilla mail (and probably add a warning banner one week in advance on every Bugzilla page).
I want to get this done before the Fremantle Alpha SDK gets released. Comments on the draft welcome.
Virtual QA Contacts
Bugzilla provides the concept of having QA Contacts and Default Assignees on a per-component level (components like Bluetooth are a sub-level of products like Connectivity are a sublevel of a categorization). QA Contacts and Default Assignees are just “users”, and every user in Bugzilla has an email address that does not need to be a valid one, let me explain:
If you are interested in getting all bugmail for a specific component, you subscribe to the email address of the particular QA Contact by adding it to your watchlist in your Email preferences in Maemo Bugzilla.
Currently there are lots of QA Contacts and Default Assignees ending with @maemo.org and some newer ones with @maemo.bugs.
Problem: foo@maemo.org email addresses exist in reality. It’s a bit unlikely that an individual will apply for the email address browser_bugs@maemo.org, but nevertheless it’s IMO bad to use an existing real domain.
Instead, I prefer to constantly use aliases with the non-existing top-level domain “.bugs” (like browser_bugs@maemo.bugs) – this is also what GNOME Bugzilla is doing by using a -maint@gnome.bugs suffix, and it has worked out quite well. (Another nice side effect of using alias is that you don’t have to reassign all bugs when a developer in a company moves on to maintain a different component – instead the former developer just removes the alias from his watchlist, and the new developer adds it to his watchlist. Less bugmail noise for everybody.)
So I’d like to harmonize this, one big problem though: Some of these addresses might exist in reality. If e.g. “sdk_bugs@maemo.org” is a real user and not a virtual one, and I change this to “sdk_bugs@maemo.bugs”, sdk_bugs@maemo.org will of course not receive any emails anymore. Need to take a look which of these users are correctly marked as inactive and probably check for the rest of them. 
Feature Jam (Go vote!)
Published a very first Feature Jar for the community and Nokia product managers one week ago. It’s rough and will soon receive another iteration. This is planned to happen monthly now. Keep in mind that Nokia handles feature requests differently from “real” bugs (other persons to contact), hence this is seperate from Bug Jars.
You can raise your voice by voting for existing bug reports and enhancement requests (much prefered to “I want this too” comments)! Every bug report has a “Vote for this bug” link. Use it! Also see the My Votes page for more information.
Cleaning up
I’ve also been spending some time on triaging dozens of old bugs (bugs, not enhancement requests) to continue cleaning up. There’s still enough reports that have never seen any comment added though, and sometimes I even have to close valid non-critical Diablo issues as WONTFIX because the issue will not exist in Fremantle anymore (radical code changes) and because the corresponding Nokia developer teams have already moved on to spend their time on Fremantle only except for critical issues. I always feel a bit sorry for this, but I understand that a company has to set priorities on where to use manpower and resources…
However, I think we’re on a good way – if you want to help, just pick up an old bug and try to reproduce it with the current Diablo. If it’s still an issue, update it by leaving a comment and setting the “Version” field to the version that you have used for testing. If you can’t reproduce, also add a comment telling us the version you’ve used and the steps you took to reproduce. Even if you only take a look at one bug, it’s an appreciated help! Also see the Bugsquad wiki page for more info in general.
