maemo.org Bugzilla 2008 statistics (1)
 

A quick look at the maemo.org Bugzilla activity of the last 366 days:


Maemo Official Applications:

• Enhancement requests:
  • 355 Total, in any state (177 of them open)
  • 140 filed in 2008
  • 132 resolved in 2008, 57 of them FIXED (43%)
  • Resolved/Filed Ratio: 0,94
• Bug reports:
  • 867 Total, in any state (255 of them open)
  • 363 filed in 2008
  • 345 resolved in 2008, 162 of them FIXED (47%)
  • Resolved/Filed Ratio: 0,95

maemo.org Bugzilla 2008 statistics (2)
 

Maemo Official Platform:

• Enhancement requests:
  • 346 Total, in any state (125 of them open)
  • 123 filed in 2008
  • 140 resolved in 2008, 67 of them FIXED (48%)
  • Resolved/Filed Ratio: 1,14
• Bug reports:
  • 1363 Total, in any state (257 of them open)
  • 350 filed in 2008
  • 420 resolved in 2008, 209 of them FIXED (50%)
  • Resolved/Filed Ratio: 1,2

maemo.org Bugzilla 2008 statistics (3)
 

Website:

• Enhancement requests:
  • 142 Total, in any state (25 of them open)
  • 54 filed in 2008
  • 72 resolved in 2008, 56 of them FIXED (78%)
  • Resolved/Filed Ratio: 1,33
• Bug reports:
  • 684 Total, in any state (56 of them open)
  • 237 filed in 2008
  • 269 resolved in 2008, 205 of them FIXED (76%)
  • Resolved/Filed Ratio: 1,14

There were 476 different bug reporters in 2008.

Top 20 reporters in 2008 by number of reports filed:

Filed reports : Reporter
94 : Ryan Abel
37 : timeless
35 : tz
23 : Matt Johnston
23 : Andre Klapper
23 : Tanya Meshkova
22 : Quim Gil
20 : Stephen Gadsby
20 : Vincent Lefevre
18 : luarvique
18 : kemarken
15 : Frantisek Dufka
15 : Andrew Flegg
15 : Marcin Juszkiewicz
14 : pgruebele
14 : Jussi Kukkonen
14 : Niels Breet
13 : David Hagood
12 : Jarmo Tikka
10 : Graham Cobb

Re: maemo.org Bugzilla 2008 statistics (1)
 

I can only say that I wish there was a better integration with the internal bugzilla.
Currently I can only ignore external bugs, but otoh maybe it's just because they can only be about stuff that is out of scope for the work ongoing: the lower layers of Fremantle have so little in common with their counterpart in Diablo that it's useless to even consider if a bug would still apply.

Re: maemo.org Bugzilla 2008 statistics (1)
 

I think the real chance for cooperation will be once fremantle is out and will actually be used on the real thing.

Re: maemo.org Bugzilla 2008 statistics (1)
 

There's a limit to how much outside pushing, cajoling etc. that we as a community can do. Members of the community working inside Nokia (e.g. you, igor ;-)) can do your bit to spread the word as to why working in the external Bugzilla is ultimately better for the platform.

As a developer who's worked at a very large software company, I know how frustrating it can be to be so far away from the users and receiving single line requirements from marketing/whomever.

Maemo Software's developers have the enviable option of working directly with the Maemo Community to turn a one line marketing requirement into an ongoing conversation with people representative of the real end-users.

Re: maemo.org Bugzilla 2008 statistics (1)
 

That is not so black and white.
Recently we have recieved permission to publish kernel code at a level that was not even imaginable before, but there are still certain areas - which i cannot mention for obvious reasons - that are still considered to be a marketing advantage and therefore cannot be published.

As you can immagine, bugs are not really so easy to partition. Consider a reporter or beta tester reporting a bug on component A which is open, but further analysys showing that it belongs to component B, which is closed.
What happens to the bug? does it disappear? does it get closed till component B is published as well?

And if the bug is assigned originally to component B, but then it is discovered to belong to component A, what happens to all the previous discussion? Does it get censored?

Or, even worse, bug in component X, from a previous sw release is obsoleted by the fact that component X is going to be dropped/replaced but that is not public yet. What should we do?

From my point of view it would be much simpler if there was _one_ bugzilla system, open to everybody, where i could debate anything regardless of who might be seeing it.

But, coming to reality, I have already stated this several times internally, and the problem is that the people who enforce certain closedness are the same ones who also support the external bugzilla and ask developers for more partecipation.

I am not going to solve the inconsistency in their behavior on their behalf.

Especially considering the tight schedules we are already required to cope with, I am not going to ask the people working for me to take the extra effort of self censor themselves while trying to do PR with the community and simultaneously not ruining the marketing strategy.

It's not their job and I don't see why they should take this unnecessary risk upon themselves.

Once we can speak freely about everything, we'll try to do it.

Re: maemo.org Bugzilla 2008 statistics (1)
 

Indeed, I was being (slightly) facetious. However to respond to some concrete examples:

There are two possible scenarios here:

1. Reporter is raising a bug against a publicly shipping version of Maemo. Doesn't matter if component-B is open or closed source, the bug still exists and needs to be triaged and dealt with.
2. Beta-tester is raising bug against an unreleased software version or device. For the first part, I'd say that as long as the "applies to version" is set to a version which is not publicly available, all bugs in that version should be hidden from people without certain privileges. If it's a hardware specific item, it belongs in some internal Nokia team's issue tracker of choice.

Now this one's actually easy. But it requires a mindshift: Bugzilla's not just for bugs in Nokia's shipping devices, but for bugs in (all versions of) Maemo.

What if the bug is in a component which is still in use in Mer? Or a Hacker Edition? The bug still affects anyone with a 770 or N8x0 who won't (probably) have the option of upgrading to a Nokia-sponsored version of Maemo 5.

The bug should remain open. Anyone can fix it in the existing component (if it's open source) and resolve it themselves.

Then expect more griping. I fully understand your position and the limitations that it brings, and I really appreciate the involvement you (and others like Eero, Roope, Quim, timeless and many more) have in the Maemo Community. But Nokia may be successful, and the Maemo-device product line(s) may be comparitively successful; but in no way are Nokia going to be fully taking advantage of the legions of people who are working for free on improving this platform to scratch their own itches.

You think that day'll come? Seems unlikely given what you've said above and that there'll always be hardware features which are confidential for reasons of commercial competitiveness.

Re: maemo.org Bugzilla 2008 statistics (1)
 

This confirms my theory that the public bugzilla is practically useless :(

Re: maemo.org Bugzilla 2008 statistics (1)
 

Generalizing isn't useful here.

Some parts of the public Bugzilla are practically useless, but there are many individual products that are quite useful. The website, for instance, handles all of its bugs through bugs.maemo.org, and Maemo Software products like MicroB and the Application Manager see lots of activity in their products.