[Brainstorm 2010] Bugzilla
 

This thread is part of the Maemo Brainstorm 2010

Can we improve the organisation of Maemo Bugzilla? Grow the bugsquad? What can we do to ensure continuity after MeeGo?

Propose your ideas and suggestions here, let's talk about it, and summarise the best ideas and conclusions in the Brainstorm 2010/Bugzilla wiki page

Re: [Brainstorm 2010] Bugzilla
 

What do you mean with this sentence?

The scope of http://bugs.maemo.org is and will be the Maemo platform.

When it comes to the platform and apps developed by Nokia, the continuity will be defined by the Maemo 5 maintenance releases. We will need to find a way to move forward to MeeGo the relevant reports not addressed in Maemo. There are several categories of reports based on the components they relate to:

- OSS components also maintained in MeeGo: should they find their way to http://bugs.meego.com ? And additional factor to consider is that even if the components are the same, in the Harmattan timeframe they will differ in packaging and perhaps this have further implications. This needs to be discussed in the MeeGo context as well.

- OSS components not maintained in MeeGo: either they move forward as MeeGo community projects or they will get out of scope somehow.

- Proprietary components common in Maemo 5 and MeeGo releases from Nokia. As I see it, the MeeGo Devices team at Nokia and the community really need to find a common agreement on these. They are the most problematic when it comes to address Bug 630 Increased Bugzilla transparency - get the developers involved!. Maybe we should remove them from any Bugzilla and place them in a different context for gathering user feedback and testing. Nokia Pilots comes to mind. I need to check with the owners of these components. If you have opinions please waive them out here.

Re: [Brainstorm 2010] Bugzilla
 

Absolutely, anything that can't be fully opened should be handled as it is in Nokia Pilots. In fact I had suggested a while back we look at the way Nokia Pilots' Bugzilla is structured and leverage what we can of that for MeeGo. And since they're already supposed to be set up to handle external participants, I would think they've already solved this. Maybe MeeGo and Maemo can both benefit.

Re: [Brainstorm 2010] Bugzilla
 

The usefulness of a bug tracker is related to the possibility that people have to fix bugs that are reported there. MeeGo thus poses certain problems - will Nokia-maintained Maemo components continue to be maintained by Nokia in the coming months & years? If not, will the community be able to fix bugs & package new images? If not, why accept bug reports in the Maemo bug database?

This is what I meant - what does the project (and the organisation of Bugzilla) need to look like in a few months, esp. if no-one from Nokia is fixing Maemo bugs any more?

I see that you understood what I meant :)

Your various questions (what happens to Maemo bugs in components that are also part of the MeeGo stack, that aren't part of the MeeGo stack, bugs in proprietary components, and can we enable the community to continue maintainership of Harmattan) are exactly the questions that are difficult to answer in the context of Bugzilla.

Cheers,
Dave.

Re: [Brainstorm 2010] Bugzilla
 

As long as there are maintenance updates for Maemo 5 in the pipeline, Nokia will keep taking bugs.maemo.org as one reference to gather user feedback. Independently from whatever new activities are happening in the MeeGo context.

The focus for Nokia on bugs.meego.com is different, since the weight of open & unstable platform development will be much bigger than the focus on end user feedback about stable releases.

Users of MeeGo based Nokia devices will give feedback mostly about a UX layer that will not be under the responsibility of the MeeGo project. Sure, some of the problems will be originated by the MeeGo platform even if the user feels the pain when doing action A with application B, but most of them won't be able to make the connection and someone will need to file the dependent bugs against the right platform components at bugs.meego.com.

In any case, as you see most of the question marks relate more to MeeGo than to bugs.maemo.org.

Re: [Brainstorm 2010] Bugzilla
 

There are a couple of forward-portable things I'd like to see implemented for Bugzilla:

First, the guided submission wizard will make both reporters' and triagers' lives much easier. Make it easy to submit useful bugs, everybody's happier and it's something we can easily take to MeeGo.

Second, and somewhat out-of-scope, I'd like to see an API and some software for collecting bug reports from within the software, while making sure we avoid the pitfalls of something like Bug Buddy.

Finally, from the community-side, I'd love to see some more structure and cheerleading to get more people involved with the bugsquad. An overwhelming portion of the triaging load is falling to paid positions (which there's nothing wrong with per se, but combined with the large volume of reports, and the limited number of paid people, it's less-than-optimal), and having more traigers looking at things will improve bug quality, reduce workloads for everybody and allow paid people to focus on higher-level stuff that they're more often the bottleneck for.

Re: [Brainstorm 2010] Bugzilla
 

Not meaning to blur lines between Maemo and MeeGo, but by all means anyone with ideas like these is more than welcome to contribute them to the MeeGo User Engagement Framework project (wiki, whitepaper, whatever):

http://wiki.meego.com/MeeGo_User_Eng...mework_Project

Re: [Brainstorm 2010] Bugzilla
 

I'd like to see bugtracker created automatically for all packages (one for source package) in extras. Bugtracker field in control files would become obsolete or it should be used only if alternate bugtracker is used. If maintainer doesn't wan't to use bugtracker for what ever reason it can be disabled.

Re: [Brainstorm 2010] Bugzilla
 

This is a feature that almost certainly requires 3.4. So, yes, once we upgrade, I agree.