Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 2 days, 8 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 3 days, 3 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 5 days, 12 hrs ago - more...
| The Following 5 Users Say Thank You to dneary For This Useful Post: | ||
 |
|
2010-05-19
, 05:57
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#2
|
Originally Posted by dneary
What do you mean with this sentence?
What can we do to ensure continuity after MeeGo?
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.
| The Following User Says Thank You to qgil For This Useful Post: | ||
 |
|
2010-05-19
, 06:32
|
|
Posts: 11,700 |
Thanked: 10,045 times |
Joined on Jun 2006
@ North Texas, USA
|
#3
|
Originally Posted by qgil
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.
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.
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
| The Following User Says Thank You to Texrat For This Useful Post: | ||
|
|
2010-05-19
, 08:26
|
|
Posts: 263 |
Thanked: 679 times |
Joined on Apr 2008
@ Lyon, France
|
#4
|
Originally Posted by qgil
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?
dneary said: What can we do to ensure continuity after MeeGo?
What do you mean with this sentence?
The scope of http://bugs.maemo.org is and will be the Maemo platform.
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?
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.
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.
| The Following 4 Users Say Thank You to dneary For This Useful Post: | ||
|
|
2010-05-20
, 05:04
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#5
|
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.
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.
 |
|
2010-05-20
, 15:34
|
|
Posts: 5,478 |
Thanked: 5,222 times |
Joined on Jan 2006
@ St. Petersburg, FL
|
#6
|
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.
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.
__________________
Ryan Abel
Ryan Abel
| The Following 6 Users Say Thank You to GeneralAntilles For This Useful Post: | ||
|
|
2010-05-20
, 15:48
|
|
Posts: 11,700 |
Thanked: 10,045 times |
Joined on Jun 2006
@ North Texas, USA
|
#7
|
Originally Posted by GeneralAntilles
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):
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.
http://wiki.meego.com/MeeGo_User_Eng...mework_Project
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
| The Following User Says Thank You to Texrat For This Useful Post: | ||
|
|
2010-06-02
, 12:17
|
|
Posts: 1,208 |
Thanked: 1,028 times |
Joined on Oct 2007
|
#8
|
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.
Last edited by mikkov; 2010-06-02 at 12:29.
Last edited by mikkov; 2010-06-02 at 12:29.
|
|
2010-06-02
, 12:26
|
|
Posts: 5,478 |
Thanked: 5,222 times |
Joined on Jan 2006
@ St. Petersburg, FL
|
#9
|
Originally Posted by mikkov
This is a feature that almost certainly requires 3.4. So, yes, once we upgrade, I agree.
I'd like to see bugtracker created automatically for all packages (one for source package) in extras. Bugtreacker 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.
__________________
Ryan Abel
Ryan Abel
| The Following User Says Thank You to GeneralAntilles For This Useful Post: | ||
 |
| Tags |
| brainstorm, bugzilla, community, maemo, testing |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 09:03.
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