Yes, I know it's currently a waste of time as it's rarely updated and contains no relevant feedback from Nokia or their developers.

I raised bug #630 some time ago to constructively criticise the current process. Sadly nothing has changed so I urge you to vote or comment on this bug in order to raise the priority. If you think I'm out of line, fair enough - leave that as a comment too!

I feel bad about giving Nokia a hard time so soon after the release of OS2006, but Nokia talk about being involved in the Open Source community yet have very little direct contact with real users as you would expect with say the Mozilla Foundation.

Key features are missing from the 770 - eg. Bluetooth audio (bug #667 - yet we have no way of knowing why, or if a solution from Nokia is in the wings. For all we know, it may be impossible to implement but it would at least be nice to know!

So come on Nokia, sort out your communication and Bugzilla management!

I've not found bugs that slow to be updated. I did a report in bugzilla and it shows almost 1 bug actioned for each day August, maybe thats not enough, but things seemed to be being addressed. Though the idea about naming the QA is a good one.

Rich

I've seen few if any bugs actioned to be honest, other than the stock response from MaemoQA "passed to upstream maintainer" (followed by silence) - perhaps it depends on our definition of action.

Personally I would prefer if the "upstream maintainers" became more directly involved with those who are reporting the bugs, rather than the bug report disappearing into a black hole ("passed to upstream maintainer") from where it may or may not reappear at some unknown time in the future with the corresponding Bugzilla update "Is this now fixed in OS200x? Thanks, MaemoQA".

The lack of progress reporting and general defect management is disheartening - how difficult would occasional updates be, such as "we've reproduced and identified the problem, a fix will be checked in for the next release"? Or "No sorry, the 770 hardware cannot support the A2DP profile because of <insert technical reason>"

I'd say the vast majority of bugs have received no response other than mass assignment to upstream maintainers (and while assignment is an action, it's not real progress).

Check out the 2GB MMC bug (bug #621) - a working patch was provided, yet we still have no indication if it will be fixed in a future release. At least MaemoQA passed it to the upstream maintainer, but without further feedback and dialog for all we know the upstream maintainer may have been hit by a bus or quit Nokia (neither of which I hope is true, naturally!)

Perhaps providing a glimpse into bugzilla will help more of the community become involved and thereby encourage more bug status updates by the maemo developers:

maemo Bug Jar - A Quick Look at maemo Bugzilla - 2008.04.17 through 2008.04.23

Bug activity this week:

• 17 new bugs were opened.
• 3 bugs were confirmed.
• 14 bugs were closed.

Ten biggest bugs by number of votes:

1. 176 - Support for OGG Vorbis / Theora missing - 96 votes
2. 2878 - Very poor satellite acquisition with internal GPS - 58 votes
3. 667 - A2DP and AVRCP Bluetooth profile wanted - 42 votes
4. 1833 - N800 to PC video calls - 42 votes
5. 1889 - Add Camera support to Flash plug-in - 41 votes
6. 1695 - Request tabs be included - 31 votes
7. 1046 - RFE: Power Management Profiles... - 30 votes
8. 2639 - Home View needs to have an option to lock... - 29 votes
9. 368 - USB mode selection on control panel - 27 votes
10. 1017 - need 802.1X/PEAPv0/MS-CHAPv2... - 23 votes

Is your pet bug not in the top ten? Please post about it (and don't forget to link to it). You might attract some votes.

I hadn't looked at #630 in a while . . . depressing. :<

An interesting table: https://bugs.maemo.org/report.cgi?x_...op&value0-0-0=

Wouldn't this thread be useful stickied and with more bugs shown here to be voted?

I think it would motivate people to vote more, and could be a starting point to newbies to get involved.

I had intended to include more bugs and additional details regarding them in my post. "Biggest Bugs by Severity" fell flat though, as after the few blockers, the mass of criticals appeared difficult to distill enough to make a top ten. Also, noting how the rankings within "Biggest Bugs by Votes" had shifted during the week didn't pan out. No rankings changed.

In any case, I'm still taken with the idea of providing a weekly snapshot of what's happening within maemo Bugzilla. I like to think that providing more frequent information about, and quick access into, the system might increase its use, ideally by all parties. In any case, I'm willing to give it a try.

So, I'm looking for suggestions. What information should I include? How should I present it? Should I just sit down and be quiet?

I like your previous idea of Biggest Bugs by Severity. I don't think you should worry so much about justifying your list statistically, as it appears you would like to do. Just an opinionated list would be fine, to me. If anyone disagrees they could create a counter-list. I don't think the FBI uses statistics to create their Most Wanted list, in terms of dollars lost in crime or people killed -- neither should you.

Most Important Bugs Fixed along with a brief explanation of what the bug actually fixes might be nice.

sjgadsby, can I send this bug to your list: metalayer-crawler grabs RAM & CPU, paralysing device.

I think a lot of people suffer from this problem (me included), but it has only 3 votes at the moment.

Edit: I totally agree with geneven.

I've practically given up on #303 :-(