When maemo.org was that site run by Nokia, then having only Nokia products in bugs.maemo.org made sense, leaving all th rest to garage.maemo.org - the official place for community / third parties.
Now this could change, since maemo.org is going to be that site run by the Maemo community, where Nokia is also one player. From a Nokia perspective it would be iindeed interesting to keep a clear line of responsibilities and expectations, but it can be possible done as well within a single bugzilla.
For instance, keping weekly reports and statistics affecting about only the platform products maintained by Nokia would be useful, and dilluting this in overall statistics wouldn't be useful. In fact we can see already today that having the Website bugs mixed with the software bugs is already distorting the picture and distracting the attention sometimes...
Another idea. Would it be possible to have two bugzilla instances reliying in fact in th same database? Same backend & same users but different frontends, one for official-platform-by-Nokia (aka "Maemo" in the new definition) and the other one for the rest: applications by Nokia/3rd partties + community platform hacks ("*** for Maemo" in the new definition).
This would work in the lines of my comments in bug 630 and would help us Maemo SW team @ Nokia concentrate our attention in the platform quality. Note that the application level is a different battle for us, even for those apps developed inside Nokia, that increasingly might come from other corners outside our own team. The application layer is also where more noiseVSsignal is likely to come as the devices running Maemo become more popular, where most closed source is located and therefor less possibilities to get contributions... Is a different game.
The platform level is where most of the open source + upstream components are concentrated, making possible to evolve to a more Debian/GNOMEish dynamics, with higher direct Nokia developer involvement, better monitoring from upstream, more contributions made via patches and a more specialized dialog overall.
And just mentioning another idea that apeared in previous discussions: using https://bugs.launchpad.net/ to integrate/aggregate everything.
For me the lauchpad approach works well. All core components of Ubuntu are mingled in with community led projects; its a central repository. Its so much easier just searching for a package on a single site than figuring out where you should file a bug. It also makes a bug reporting/crash reporting tool something of a reality where you can file bugs easily to one place.
Combine the two but please, the current offerings needs a lot of love to tidy them up.
@baloo:
Launchpad definitely has some advantages. But one disadvantage that really drives me nuts is that bug searching is really bad. I'm never able to find the bug reports I'm searching for though I do know about the words to use - I've been successfully finding my reports in GNOME Bugzilla for years now.
And I don't see a crash reporting tool yet like Apport (Ubuntu) or Bug-Buddy (GNOME) for Maemo, and in general it seems to me that Maemo doesn't have that many crashers.
@qgil:
I think the whole post leads to the question how to provide best solutions for both community projects and "official" Maemo components.
One option could be to set a flag for any "official" Maemo components, and basing report scripts or queries on that. Having some predefined queries, kinds of "defined views" like in databases. But Karsten should be able to answer this much better as he is currently looking at the code.
Trac is certainly nice, but it has a few disadvantages, e.g. you can't reference bug IDs when marking duplicates and you can't reference bug dependencies. However it's definitely one of the better bug tracking systems, and as an advantage, it has source browsing integrated. The question is: Do we need/want it?
I agree that trac is very nice, and missing features can be (or havealreadybeen) implemented as plugins (IMHO it's very hackable - speaking as someone with hardly any Python experience who has written a few plugins already). It certainly could be used instead of gforge for garage hosting. The fedora people have deployed it in a similar fashion for example.
On the other hand I think consistency matters a lot, for reporters, developers and bugmasters alike. If the garage tracker must be replaced (yes, please) then bugzilla is probably the way to go.
On the other hand I think consistency matters a lot, for reporters, developers and bugmasters alike. If the garage tracker must be replaced (yes, please) then bugzilla is probably the way to go.
++
Switching to something else for the sake of switching to something else is a bad plan. A lot of the Maemo community is already familiar with bugzilla, no sense throwing another wrench into things with a completely different bug tracker.
Switching to something else for the sake of switching to something else is a bad plan. A lot of the Maemo community is already familiar with bugzilla, no sense throwing another wrench into things with a completely different bug tracker.
I put together a proposal on the wiki, it's a pretty general overview at this point, and a lot of the details still need to be pounded out, but the talk page there would be a good place to open more detailed discussion.
On the technical side of things, timeless played with a classification system that separates the Maemo Software, Website, and Garage stuff from each other on bugzilla (you can see the classification in brackets next to the bug number), and solves most of the "clutter" issues pretty well.
Anyway, this is something I'd like to see pushed forward, we just need to deal with some technical issues and get some real input from the Garage projects that actually use the Garage tracker.
