Some of you may have noticed mail announcing changes to bugs.maemo.org that was sent out over the weekend. While this is not entirely browser related, it was done mostly by me with the hope of improving the Browser team's ability to collect, analyze and resolve bugs in MicroB. As some people know, among my other hats, I am occasionally involved in the configuration of components for another Bugzilla, and while I don't remember the absolute beginning of that Bugzilla, or its community, I'm hoping that we can grow the maemo.org community to be as active and involved as theirs.
maemo.org is a software platform, and while its sponsor thinks about hardware, we don't. Software tends to outlive hardware and bugs in one version of a product tend to continue to future versions.
You have a couple of options:
maemo.org is hosting this bug tracker and the SDK versions are what they ship, it's unfair to force maemo.org to deal with numbers they don't really understand.
Because I can't find anyone with a working secret decoder ring for them, and they don't sort well.
This information is collected from Nokia 770 flash downloads, Nokia N800 flash downloads, and repository.maemo.org:
Products are used to describe categories of applications, and programs are organized according to those categories. I've also created more components to match programs you actually see.
We ask that you try your best to pick the right component. firstname.lastname@example.org still exists (it's really more of a person than an account, more on that later), but as of this morning it will get mail for most new bugs (just like it used to).
You should also try using the search form, not just to see if your bug is filed, but to get an idea about where similar bugs have already been filed. If you browse through the components list, you will see that there are components for the Virtual keyboard (vkb) and Finger keyboard (fkb) hidden under System software.
I couldn't come up with a better place according to the metaphor we were using, if you think there's a better place for it, tell Quim Gil, as this is his show (i.e., he does speak for maemo.org, and I will make changes as he requests them).
There are a number of ways, but one way is to pick a couple of components that interest you, or which you know about, or are willing to learn, or happen to use and set up user watching. Once you've done that, look through the bugs in each of those components, try to figure ouf if they belong there or should be moved somewhere else. This is especially true with e.g., Media player, one of the last components I moved, many of the bugs probably belong in Multimedia framework. One bug is about metalayer-crawler, which probably needs its own home.
If you can, please try to reproduce the problem. If you think the problem is not reproducable, write a comment indicating the version you tested, the steps you took, the results you got, and why you think the bug WORKSFORME.
If you think a bug isn't clear (many bugs aren't), and can offer more detailed steps, please add a comment with them. In many cases a url or attachment will help. You should be able to create attachments or fill in the URL field. If you need help making changes to bug fields (see editbugs below), just comment describing what changes you want made or ask for help from #maemo. I'll try to have a couple of people there who can help out.
If you think a bug isn't clear and you can't figure out what the reporter is asking or describing, please leave a polite comment in the bug explaining what is unclear and ask for clarification. Please be civil, we're trying to grow a community, not start wars.
User watching lets you have the same chances to get mail as another user according to the role and relation that user has to a bug.
New components will generally have a default assignee of mailto:email@example.com and a QA contact something like: mailto:firstname.lastname@example.org. I personally watch this account. This means that I can get mail for all bugs filed in the Browser:MicroB engine component.
While I tried my best to find an appropriate home for each bug, I moved nearly 1900 of them, and everyone makes mistakes. If a bug is open and you choose to move it, if you have editbugs, then please be sure to select (*) Reassign bug to default assignee and QA contact. If you don't have this bit set in permissions, then you won't see that option. In which case someone else will have to fix it later. Hopefully someone watching the old component will notice the move mail and reassign.
There are just over 1900 bugs in bugs.maemo.org, about 50 of them are not public. I've personally burried one because it was spam for an adult site. Most relate to various SDKs which are being beta tested for release.
Contact email@example.com and give a reason why you think it should be public or why you think you should be able to see it. If QA agrees that you should be able to see it, QA can add you to the CC list and you will then be able to review the bug yourself. A number of the hidden bugs are filed about old SDKs, so one of the other tasks on my ever growing to-do list is to try to get them declassified. Most bugs are not secrets, nor are they even interesting. Believe me, I had one secret bug filed about me this month, and like you, I was not able to see it. But once I read it, I was amazed at how bland it was.