Defining the Maemo Bugzilla scope
 

Currently Maemo Bugzilla is used as a bug tracking system for the "core" software elements shipped in the Maemo platform (to define the term "Maemo" itself, please see this discussion). This includes both Open source and Closed source components preinstalled on the devices by Nokia. Obviously this does not include stuff like Skype or Rhapsody - they have their own bugtrackers.

And there is Garage Tracker. It is the bugtracking system for all those products based on the Maemo stack, but not preinstalled on the devices by Nokia.

In my opinion and in the long run, Garage tracker should die. Maemo Bugzilla shall be the main bugtracking place for all products based on the Maemo stack. I just didn't like working in Garage Tracker (have to admit that I just took some quick looks to synchronize the status of reports that were duplicated in Maemo Bugzilla). It reminded me a lot of that awful bug tracker that Sourceforge provided when I had a small software project hosted over there, but it may be only my personal opinion that Bugzilla is easier and better to handle than Tracker is.

So I wonder: Are Garage project maintainers happy with Garage tracker?
Would they be interested to track their bugs in Maemo Bugzilla instead? My (not even reasonible or founded) dislike of the Garage Tracker is entirely my personal opinion after working with several bug trackers in the past. I want your opinions - It does not make sense to think about this too much if everybody is fine with Garage Tracker. ;-)

And which projects should be handled in Maemo Bugzilla? Keep it in the current state, as described at the beginning? Open it up for everybody interested in using Maemo Bugzilla to keep track of issues in his/her Maemo based software?

The latter one would bring up the next question that Quim raised in the famous bug 630: Are then the apps preinstalled in a device, »maemo compatible applications«, a different layer sitting on top of the maemo software platform? Stuff to think about, looking forward to your comments!

Andre Klapper (Maemo.org bugmaster)

Re: Defining the Maemo Bugzilla scope
 

Having multiple locations for bug reporting/hunting is cumbersome, to say the least.
Unsurprisingly, it relates to the "multiple repositories and poor QA situation" discussed a while ago.

As much as I do love Bugzilla (and use it daily, since around 2000), it can be intimidating (like most BTS) for newbies or the average joe-user.
I also share your personal dislike of Garage (GForge) tracker.

Maemo heavily inherits from Debian, so how about adopting its well-integrated support infrastructures too ?
How about using debbugs ?
While (as a BTS) it's less powerful than Bugzilla (e.g. Queries), its integration with the package management flow makes it a great system.

Ultimately, the BTS should handle *every package* served by the official & extras repositories... but not to any Maemo-based project.
Ideally, this would serve as an incentive to move into extras...

Re: Defining the Maemo Bugzilla scope
 

Personally, I find the gforge tracker to be rather unbearable. That said, I'm not in love with the idea of merging the Maemo Bugzilla (emphasis on Maemo) with the Garage projects at this point in time. I believe it's important to keep the official Nokia tracker and the community tracker separate for the time being.

Re: Defining the Maemo Bugzilla scope
 

I have reply in the andre blog, saying that I agreed to unify the garage tracker with the bugzilla. The worst thing can be the users relate the 3rd party apps with Nokia. And it would be to bad thing.

Probably it's not a good idea to have only a bugzilla for maemo and 3rd party apps, but IMHO it would be much better than garage trackers to have a bugzilla unifying all the 3rd party apps. Well for those developers who want it.

Re: Defining the Maemo Bugzilla scope
 

Thanks guys for your feedback! So far it seems that developers don't really care (or neither read itt, maemo-developers mailing list or planet maemo). Let's see how this continues, but right now I tend to keep the current state, just not many complaints about Garage Tracker.
Priority could of course change again if tomorrow suddenly 20 garage developers come up screaming and cheerleading for bugzilla. :D

Re: Defining the Maemo Bugzilla scope
 

Bugzilla sucks - just not as much as Garage Tracker.

I'd love to manage my projects' issues in Bugzilla, but also worry about polluting the main Bugzilla with it.

How feasible is running *two* Bugzillas? One for the community, one for the Maemo platform?

Re: Defining the Maemo Bugzilla scope
 

If separating them, why not using something more user friendly than bugzilla - like Trac for instance - it integrates rather nicely with SVN too.

Re: Defining the Maemo Bugzilla scope
 

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? :confused:

Re: Defining the Maemo Bugzilla scope
 

@Jaffa:

> I'd love to manage my projects' issues in Bugzilla, but also worry
> about polluting the main Bugzilla with it.
>
> How feasible is running *two* Bugzillas? One for the community,
> one for the Maemo platform?

What's the advantage of having this seperately? And what exactly do you mean by "pollution"? GNOME Bugzilla also hosts ~300 products and I wonder which disadvantages you see that you call pollution. :)

Re: Defining the Maemo Bugzilla scope
 

I'd definitely prefer Bugzilla if we're going to be moving to anything for Garage.

I guess the issue is having Garage-related noise in the official Nokia tracker. I have the same (mostly gut-level here) reservations with this as Jaffa, but there's probably bit of perspective involved. My own experience with Bugzilla is limited to Maemo's Bugzilla, so I can't really speak to any concrete experience-derived reservations about bringing Garage projects into Bugzilla proper.

Re: Defining the Maemo Bugzilla scope
 

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.

Re: Defining the Maemo Bugzilla scope
 

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.

Re: Defining the Maemo Bugzilla scope
 

@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.

Re: Defining the Maemo Bugzilla scope
 

I agree that trac is very nice, and missing features can be (or have already been) 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.

Re: Defining the Maemo Bugzilla scope
 

++

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.

Re: Defining the Maemo Bugzilla scope
 

Second that and totally agree with you.

Re: Defining the Maemo Bugzilla scope
 

A little bit of an update here.

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.