MeeGo wiki - User contributions [en]

Quality/Bugzilla Fields

2011-07-15T06:20:43Z

Wanshuang: /* Flag */

==MeeGo Release==

MeeGo Release field defines in which MeeGo version a bug has been found.
Version names are defined according to the [[Release_Engineering/Plans|MeeGo release plan]]. If a bug was reported already for an older MeeGo version make sure to [[Quality/defects#Bug Cleanup after Project Release|handle this bug as described here]].

==Target Build==

The main purpose of this field is for developers to predict on which build the bug can be fixed.

When developers get a bug and acknowledge the issue, they are expected to change the status from NEW to ASSIGNED, and set a Target Build to forecast when the issue can be fixed.

==Importance==
===Priority===

Priority field describes the importance and order in which a bug should be fixed. It helps developers to prioritize their work. By default the priority is set as "Undecided" when reporting a new bug. A bug triage team sets the initial priority for the bug, which might be changed. Priorities range from High (most important) to Low (least important).
* High: Bug fixing is on-going, or is planned within 2 weeks, no later than the up-coming milestone. Reproducible crash issues, major function loss, issues greatly impact user experience or issues which block other key features to work would fall in to this category.
* Medium: Bug fixing is planned before project release, but can't start before HIGH priority items are cleaned up.
* Low: Bug fixing is not planned for the up-coming project release. Will re-evaluate the importance in next release.

===Severity===

The "Severity" field describes the impact of an issue. The options include:

* Critical: crashes, other components are affected
* Major: major loss of own function
* Normal: regular issue, some loss of functionality under specific circumstances
* Trival:cosmetic problem like misspelled words or misaligned text
* Enhancement: request for enhancement

==Profile, Architecture and Platform==
===Profile===

The type of device (like Netbook, Nettop, Notebook, Handset, Automotive, TV) the issue has been identified in.
For bugs which apply to all UX (like bugs for Middleware/Core components), then "Common" should be selected.

===Architecture===

The architecture (like [[:wikipedia:Intel Atom|IA]], [[:wikipedia:ARM architecture|ARM]]) the issue has been identified in. For example N900 Base OS layer bugs are ARM, most Netbooks are IA.
For bugs which apply for multiple architectures, like bugs for middleware or applications, there is "All".

===Platform===

Platform field indicates the hardware platform against which the bug is detected, like ExoPC, Moorsetown, N900, Oaktrail, etc.

==Keywords==

[https://bugs.meego.com/describekeywords.cgi Keywords] can be added to reports to quickly find issues of the same keyword category across various products and components.

The adding and deleting of keywords will follow the [http://wiki.meego.com/Quality/BugzillaRequestProcess common process of changes in Bugzilla] 

==See Also==

This allows you to refer to bugs in other installations. You can enter a URL to a bug in the "Add Bug URLs" field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma.
 You should normally use this field to refer to bugs in other installations. For bugs in this installation, it is better to use the '''Depends On''' and '''Blocks''' fields.

==PM Comment==

This field is for MeeGo PM team to record the TODOs, AR (Action Required), etc for MeeGo release key issues. By using this field, PM comments can be easily found. And meanwhile, PM is able to export the data in custom field easily for further using.
* See [https://bugs.meego.com/show_bug.cgi?id=16304 this report] for the request for addition of a custom PM comment field.

==Triaged By==

"Triaged By" is used to track who in-depth triaged a bug report. This field is intended to be used by system debug engineers.
* Please refer to [http://wiki.meego.com/Quality/SysDebug SysDebug] for more information on usage of this field.

==Flag==
We use these customized flags to manage release blocker bugs.
* '''MeeGo_Update_Release_Blocker'''.
* '''MeeGo_Release_Blocker'''.
* '''MeeGo_N900DE_Release_Blocker'''.
* '''MeeGo_Tablet_Change_Control_List'''.

Any users can propose blocker bugs for a specific release, and users in a priviliged groups, like Program Managers, approve/reject these blockers.

'''TODO:''' ''(This process needs documentation)'' --[[User:Andre|Andre]] 10:14, 13 June 2011 (UTC).

 MeeGo release version and these blocker flags are used together to identify blocker issues in each releases uniquely.
* See [https://bugs.meego.com/show_bug.cgi?id=9533 this report] for the request for addition of a MeeGo_Update_Release_Blocker field.

==Other reference pages==
* [[Quality/Bugtriage|MeeGo Bug Triage]]
* [[Quality/Bug_Life_Cycle_and_Handling|Bug Life Cycle and Report Handling/Follow-up Guidelines]]
* [[Quality/How_To_Report_Bugs|How to report bugs]]

[[Category:QA]]

Quality/Bugzilla Fields

2011-07-14T05:50:35Z

Wanshuang: /* Flag */

==MeeGo Release==

MeeGo Release field defines in which MeeGo version a bug has been found.
Version names are defined according to the [[Release_Engineering/Plans|MeeGo release plan]]. If a bug was reported already for an older MeeGo version make sure to [[Quality/defects#Bug Cleanup after Project Release|handle this bug as described here]].

==Target Build==

The main purpose of this field is for developers to predict on which build the bug can be fixed.

When developers get a bug and acknowledge the issue, they are expected to change the status from NEW to ASSIGNED, and set a Target Build to forecast when the issue can be fixed.

==Importance==
===Priority===

Priority field describes the importance and order in which a bug should be fixed. It helps developers to prioritize their work. By default the priority is set as "Undecided" when reporting a new bug. A bug triage team sets the initial priority for the bug, which might be changed. Priorities range from High (most important) to Low (least important).
* High: Bug fixing is on-going, or is planned within 2 weeks, no later than the up-coming milestone. Reproducible crash issues, major function loss, issues greatly impact user experience or issues which block other key features to work would fall in to this category.
* Medium: Bug fixing is planned before project release, but can't start before HIGH priority items are cleaned up.
* Low: Bug fixing is not planned for the up-coming project release. Will re-evaluate the importance in next release.

===Severity===

The "Severity" field describes the impact of an issue. The options include:

* Critical: crashes, other components are affected
* Major: major loss of own function
* Normal: regular issue, some loss of functionality under specific circumstances
* Trival:cosmetic problem like misspelled words or misaligned text
* Enhancement: request for enhancement

==Profile, Architecture and Platform==
===Profile===

The type of device (like Netbook, Nettop, Notebook, Handset, Automotive, TV) the issue has been identified in.
For bugs which apply to all UX (like bugs for Middleware/Core components), then "Common" should be selected.

===Architecture===

The architecture (like [[:wikipedia:Intel Atom|IA]], [[:wikipedia:ARM architecture|ARM]]) the issue has been identified in. For example N900 Base OS layer bugs are ARM, most Netbooks are IA.
For bugs which apply for multiple architectures, like bugs for middleware or applications, there is "All".

===Platform===

Platform field indicates the hardware platform against which the bug is detected, like ExoPC, Moorsetown, N900, Oaktrail, etc.

==Keywords==

[https://bugs.meego.com/describekeywords.cgi Keywords] can be added to reports to quickly find issues of the same keyword category across various products and components.

The adding and deleting of keywords will follow the [http://wiki.meego.com/Quality/BugzillaRequestProcess common process of changes in Bugzilla] 

==See Also==

This allows you to refer to bugs in other installations. You can enter a URL to a bug in the "Add Bug URLs" field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma.
 You should normally use this field to refer to bugs in other installations. For bugs in this installation, it is better to use the '''Depends On''' and '''Blocks''' fields.

==PM Comment==

This field is for MeeGo PM team to record the TODOs, AR (Action Required), etc for MeeGo release key issues. By using this field, PM comments can be easily found. And meanwhile, PM is able to export the data in custom field easily for further using.
* See [https://bugs.meego.com/show_bug.cgi?id=16304 this report] for the request for addition of a custom PM comment field.

==Triaged By==

"Triaged By" is used to track who in-depth triaged a bug report. This field is intended to be used by system debug engineers.
* Please refer to [http://wiki.meego.com/Quality/SysDebug SysDebug] for more information on usage of this field.

==Flag==
We use these customized flags to manage release blocker bugs.
* '''MeeGo_Update_Release_Blocker'''.
* '''MeeGo_Release_Blocker'''.
* '''MeeGo_N900DE_Release_Blocker'''.

Any users can propose blocker bugs for a specific release, and users in a priviliged groups, like Program Managers, approve/reject these blockers.

* '''MeeGo_Tablet_Change_Control_List'''.
The usage of this flag is same with other release blocker flags. The purpose of this flag is to propose & approve change control bug list for MeeGo Tablet.

'''TODO:''' ''(This process needs documentation)'' --[[User:Andre|Andre]] 10:14, 13 June 2011 (UTC).

 MeeGo release version and these blocker flags are used together to identify blocker issues in each releases uniquely.
* See [https://bugs.meego.com/show_bug.cgi?id=9533 this report] for the request for addition of a MeeGo_Update_Release_Blocker field.

==Other reference pages==
* [[Quality/Bugtriage|MeeGo Bug Triage]]
* [[Quality/Bug_Life_Cycle_and_Handling|Bug Life Cycle and Report Handling/Follow-up Guidelines]]
* [[Quality/How_To_Report_Bugs|How to report bugs]]

[[Category:QA]]

Quality/Bugzilla Fields

2011-07-14T05:42:15Z

Wanshuang: /* Flag */

Quality/MeeGoBugzillaRequestProcess

2011-06-17T13:18:04Z

Wanshuang: /* How MeeGo Bugzilla requests are handled */

=Processes to handle MeeGo Bugzilla Requests=

DRAFT STATUS - see [http://lists.meego.com/pipermail/meego-qa/2011-June/001940.html mailing list thread]

This process is to ensure new features or changes to MeeGo Bugzilla itself are implemented & deployed under the planned way and also to ensure the MeeGo Bugzilla features & changes are generic enough for most users.

==How MeeGo Bugzilla requests are handled==
* Have a [https://bugs.meego.com/enter_bug.cgi?product=bugs.meego.com bug report] or [https://bugs.meego.com/enter_bug.cgi?product=bugs.meego.com%20Features feature request] for the complete requests both for code level and new custom fields & new flags;
* Error management team will provide feedback in one working day normally once receive the request notification;
* The follow up and feedbacks should happen in the bug/feature comments in the report;
* For minor change like component adjustment and component owner changes, MeeGo Bugzilla admins will go ahead directly but nice to have a ticket.

==Process to accept & review & integrate code level changes==
* There will be a personal repository branch for each one has the source code submission privilege in [http://gitorious.net/meego-bugzilla MeeGo Bugzilla git repository];
* Submit the new feature & bug fix into personal repository branch;
* Merge the changes into staging branch after code cross review;
* Deploy the changes into staging Bugzilla;
* Feedbacks from testing on our staging instances ([https://01.bugs-dev.meego.com/ 1], [https://02.bugs-dev.meego.com/ 2]);
* Merge the changes from staging branch to production branch once code quality is good enough;
* Deploy the changes into production Bugzilla;

Quality/MeeGoBugzillaRequestProcess

2011-06-17T05:27:09Z

Wanshuang:

'''Processes to handle the MeeGo Bugzilla Requests'''

This process is to ensure the MeeGo Bugzilla new features or changes are implemented & deployed under the planned way and also ensure the MeeGo Bugzilla features & changes are generic enough for most of users.

*Here is the brief process summary of how MeeGo Bugzilla request is handled:
** Have a bug entry or feature entry for all change requests both for code level and new custom fields & new flags;
** Error management team will provide feedbacks in one working day normally once receive the request notification;
** The follow up and feedbacks could be happened at bug/feature comments;
** Use Severity field to identify how urgent & important the request is;
** The bug or feature assignee will use priority field to identify how urgent and important the request is;
** Use target milestone to indentify when the change could be ready especially for large changes need the code level customization;
** For minor change like component adjustment and component owner changes, MeeGo Bugzilla admins will go ahead directly but nice to have a bug entry for change request;

*To ensure the quality of changes bring to MeeGo bugzilla, here is the process to accept & review & integrate code level changes
** There will be a personal repository branch for each one has the source code submission privilege in MeeGo Bugzilla git repository;
** Submit the new feature & bug fix into personal repository branch;
** Merge the changes into staging branch after code cross review;
** Deploy the changes into staging Bugzilla;
** Feedbacks from testing on our staging instances;
** Merge the changes from staging branch to production branch once code quality is good enough;
** Deploy the changes into production Bugzilla;

*To file a new MeeGo Bugzilla change request, please click here [[https://bugs.meego.com/enter_bug.cgi?product=bugs.meego.com|Here]]

*To file a new MeeGo Bugzilla feature request, please click here [[https://bugs.meego.com/enter_bug.cgi?product=bugs.meego.com%20Features|Here]]

Quality/MeeGoBugzillaRequestProcess

2011-06-17T05:25:53Z

Wanshuang:

'''Processes to handle the MeeGo Bugzilla Requests'''

This process is to ensure the MeeGo Bugzilla new features or changes are implemented & deployed under the planned way and also ensure the MeeGo Bugzilla features & changes are generic enough for most of users.

*Here is the brief process summary of how MeeGo Bugzilla request is handled:
** Have a bug entry or feature entry for all change requests both for code level and new custom fields & new flags;
** Error management team will provide feedbacks in one working day normally once receive the request notification;
** The follow up and feedbacks could be happened at bug/feature comments;
** Use Severity field to identify how urgent & important the request is;
** The bug or feature assignee will use priority field to identify how urgent and important the request is;
** Use target milestone to indentify when the change could be ready especially for large changes need the code level customization;
** For minor change like component adjustment and component owner changes, MeeGo Bugzilla admins will go ahead directly but nice to have a bug entry for change request;

*To ensure the quality of changes bring to MeeGo bugzilla, here is the process to accept & review & integrate code level changes
** There will be a personal repository branch for each one has the source code submission privilege in MeeGo Bugzilla git repository;
** Submit the new feature & bug fix into personal repository branch;
** Merge the changes into staging branch after code cross review;
** Deploy the changes into staging Bugzilla;
** Feedbacks from testing on our staging instances;
** Merge the changes from staging branch to production branch once code quality is good enough;
** Deploy the changes into production Bugzilla;

*You have a change request? File a ticket [[https://bugs.meego.com/enter_bug.cgi?product=bugs.meego.com|Here]]

*You have a feature request? File a ticket [[https://bugs.meego.com/enter_bug.cgi?product=bugs.meego.com%20Features|Here]]

Quality/MeeGoBugzillaRequestProcess

2011-06-17T05:20:32Z

Wanshuang:

Quality

2011-06-17T05:17:23Z

Wanshuang: /* Defect tracking */

= Quality =

This page is for MeeGo Quality Assurance related material.

== Projects ==

For all test reports see [http://qa-reports.meego.com http://qa-reports.meego.com]

{| border = 1 valign="top"
! Release
! Core OS
! Handset UX
! Tablet UX
! Netbook UX
! SDK
! In Vehicle Infotainment
|-
| Release 1.3
|
* [[/Plans/MeeGo Core Test Plan | MeeGo Core Test Plan]]
* [[/TestSuite/MCTS | MeeGo Core Test Suite (MCTS)]]
* [http://qa-reports.meego.com/1.3/Core Core Test Reports]
* [[Quality/CoreQualityMetrics | Quality Metrics]]
|
* [[Quality/Plans/Handset UX test plan|MeeGo HandSet UX Test Plan]]
* [http://meego.gitorious.org/meego-quality-assurance/handset-ux-tests Test Suite]
* [http://qa-reports.meego.com/1.3/Handset Handset Test Reports]
|
* Tablet UX Test Plan
* Tablet UX Test Suite
* [http://qa-reports.meego.com/1.3/Tablet Tablet Test Reports]
|
* Test Plan
* [[Quality/Netbook_Test_Suite_and_Utilities|Test Suites and Utilities]]
* [http://qa-reports.meego.com/1.3/Netbook Netbook Test Reports]
|
* [[SDKTestPlan|Test Plan]]
* Test Suite
* [http://qa-reports.meego.com/1.3/SDK SDK Test Reports]
|
* [[/Plans/IVI Test Plan | MeeGo IVI Test Plan]]
* IVI Test Suite
* [http://qa-reports.meego.com/1.3/IVI IVI Test Reports]
* [[Quality/IVIQualityMetrics | Quality Metrics]]
|-
| Release 1.2
|
* [[/Plans/MeeGo Core Test Plan | MeeGo Core Test Plan]]
* [[/TestSuite/MCTS | MeeGo Core Test Suite (MCTS)]]
* [http://qa-reports.meego.com/1.2/Core Core Test Reports]
* [[Quality/CoreQualityMetrics | Quality Metrics]]
|
* [http://wiki.meego.com/Quality/Plans/1_2_Handset_UX_test_plan MeeGo HandSet UX Test Plan]
* [[Quality/TestSuite/handset-test-suite|Test Suite]]
* [http://qa-reports.meego.com/1.2/Handset Handset Test Reports]
* [[Quality/HandsetQualityMetrics|Quality Metrics]]
|
* Test Plan
* Test Suite
* [http://qa-reports.meego.com/1.2/Tablet Tablet Test Reports]
* [[Quality/TabletQualityMetrics | Quality Metrics]]
|
* [http://wiki.meego.com/Quality/1.2NetbookTestPlan 1.2 SW Update Test Plan]
* [[Quality/Netbook_Test_Suite_and_Utilities|Test Suites and Utilities]]
* [http://qa-reports.meego.com/1.2/Netbook Netbook Test Reports]
|
* [[SDKTestPlan|Test Plan]]
* Test Suite
* [http://qa-reports.meego.com/1.2/SDK SDK Test Reports]
|
* Test Plan
* Test Suite
* [http://qa-reports.meego.com/1.2/IVI IVI Test Reports]
* [[Quality/IVIQualityMetrics | Quality Metrics]]
|}

== QA tools ==

Quality assurance tools are developed to ensure MeeGo SW quality. They are developed and maintained by QA tools team.
* [[Quality/QA-tools|Meet the team and find our tools]]
* [[Quality/QA tools development|Participate in development activities]]. You are most welcome!

The following links provide some basic information on QA tools and their usage.
* [[Quality/QA-tools/How_to_set_up_repositories|Setting up the repositories for installing tools]] (please note that not all tools are in these repositories yet)
* [[Quality/QA-tools/Test packaging|Test packaging]]: Test packaging is the mechanism to wrap any tests in rpm packages to automate execution.
* [[Quality/QA-tools/Autotest-guide|Autotest-Guide]]: A guide for setting up automated testing environment. It includes instructions how to automate test execution and image installations.

== Procedures and best practices ==

* [[Quality/Plans/Testability-checklist|Feature Testability Checklist]]
** The basic intent of the feature review is to make sure that all features/requirements defined for MeeGo release are '''testable'''. The target is to map test cases in Distro testing against requirements, so we can determine whether features are '''done'''. This checklist / guideline should be used when reviewing MeeGo's features. Review comments will be given based on this checklist.
* [[Quality/Testability-commenting|Testability Commenting Guide]]
** This is a guide for QA contacts about how to comment on feature testability so as to provide as much information as possible to test developers.
*[[Quality/TestSuite/MCTS/MCTS_Development_Guideline | MeeGo Core Test Suites Development Guidelines]] 
*[[MeeGo Core Test Suites Packaging draft]] 
* [[Quality/Plans/Test-plan-template|Test plan template]] -- PROPOSAL, please contribute
* [[CompTestPlanTemplate|Component Test Plan Template]] -- WORK IN PROGRESS, please contribute
* [[Quality/Test_case_template|Test Case Template]] -- Updated, ready for approval
* [[Quality/TestDesignProcessAndGuideline| Test Design Process and Guideline]] -- WORK IN PROGRESS, please contribute
* [[Quality/TestSetGuideline| Test Set Guideline]]
* [[Quality/Test management overview|Test management overview]]

== Defect tracking ==

* [[/defects | Defects Management]]
* [[/Bug_Life_Cycle_and_Handling|Bug Life Cycle and Report Handling/Follow-up Guidelines]]
* [[/Bugzilla_Fields|Fields in a bug report]]
* [[/Bugtriage | MeeGo Bug Triage]]
* [[/Bugtriage_Stock_Answers | MeeGo Bug Triage Stock Answers]] -- WORK IN PROGRESS, please contribute
* [[/SysDebug | MeeGo Sys-Debug]] (finding the right component for a report)
* [[/How_To_Report_Bugs|How to report bugs]]
* [[/Bug_Access_Restrictions|Bug Report Access Restrictions]]
* [[MeeGoBugzilla_Customization|Bugzilla customized features]]
* [[/MeeGoBugzillaRequestProcess|Requests for changes in Bugzilla code/UI itself]]

== Error Management ==
See the [[Quality/Error Management]] subpage.

== Compliance Program ==
[[Quality/Compliance | MeeGo Compliance Program]] - the compliance spec (initially)

== Contact ==

* Mailing List: [http://lists.meego.com/listinfo/meego-qa MeeGo-QA]
* IRC: Channel #meego-qa on irc.freenode.net

=== Meetings ===

General QA Meetings are held weekly on Tuesdays 07:00 UTC in the channel #meego-meeting on irc.freenode.net. [[Quality/Meetings|Click here for more information.]]

QA Tools meetings are held weekly on Tuesdays 08:00 UTC in the channel #meego-meeting2 on irc.freenode.net. [[Quality/QA-tools/Meetings|Click here for more information.]]

For information on triaging meetings for specific areas [[Quality/Bugtriage#MeeGo_Bug_Triage_Meetings|click here]].

== See also ==

* [[/Glossary | QA Glossary ]]
* [[/Test_areas_and_types | Short descriptions for Test Areas/Types]]
* [[Quality/Plans/Quality-considerations|Quality Considerations / Testing Quality Characteristics]]
** Some ideas around testing quality characteristics hopefully helping you identify what kind of things could be checked from applications - can be used as a frame to define test considerations – as a set of logical test cases - for applications targeting to run on MeeGo.

[[Category:QA]]

Quality/BugzillaRequestProcess

2011-06-17T05:15:47Z

Wanshuang: moved Quality/BugzillaRequestProcess to Quality/MeeGoBugzillaRequestProcess

#REDIRECT [[Quality/MeeGoBugzillaRequestProcess]]

Quality/MeeGoBugzillaRequestProcess

2011-06-17T05:15:47Z

Wanshuang: moved Quality/BugzillaRequestProcess to Quality/MeeGoBugzillaRequestProcess

'''Processes to handle the MeeGo Bugzilla Requests'''

This process is to ensure the features or changes are implemented & deployed under the planned way and also ensure the feature is generic enough for most of users.

*Here is the brief process summary of how MeeGo Bugzilla request is handled:
** Have a bug entry or feature entry for all change requests both for code level and new custom fields & new flags;
** Error management team will provide feedbacks in one working day normally once receive the request notification;
** The follow up and feedbacks could be happened at bug/feature comments;
** Use Severity field to identify how urgent & important the request is;
** The bug or feature assignee will use priority field to identify how urgent and important the request is;
** Use target milestone to indentify when the change could be ready especially for large changes need the code level customization;
** For minor change like component adjustment and component owner changes, MeeGo Bugzilla admins will go ahead directly but nice to have a bug entry for change request;

*To ensure the quality of changes bring to MeeGo bugzilla, here is the process to accept & review & integrate code level changes
** There will be a personal repository branch for each one has the source code submission privilege in MeeGo Bugzilla git repository;
** Submit the new feature & bug fix into personal repository branch;
** Merge the changes into staging branch after code cross review;
** Deploy the changes into staging Bugzilla;
** Feedbacks from testing on our staging instances;
** Merge the changes from staging branch to production branch once code quality is good enough;
** Deploy the changes into production Bugzilla;

2010-11-22T07:49:43Z

Wanshuang: /* Bug Reporting/Follow-up Guideline */

=Getting started=
All you need is an account to be able to file and comment on reports. The http://bugs.meego.com authentication system is integrated with the http://meego.com authentication system, so the same account is used for both sites. To create a MeeGo account visit the [http://meego.com/user/register registration page]. Soon after you will receive an email with a link that must be visited to confirm your account creation. You will have to change your password on meego.com before attempting to log into Bugzilla.

=Bugzilla Fields=
==MeeGo Release==

MeeGo Release field defines in which MeeGo version a bug has been found. Version names are defined according to the [http://wiki.meego.com/Release_Engineering/Plans MeeGo release plan].

==Target Milestone==

When bugs are in OPEN or RESOLVED status, it is used by the bug reporter to propose which milestone this bug is expected to be fixed.

* --- Undecided
* 1.0 Propose bug is expected to be fixed in 1.0
* 1.1 Propose bug is expected to be fixed in 1.1

==Importance==
===Priority===

Priority field describes the importance and order in which a bug should be fixed. It helps developers to prioritize their work. By default the priority is set as "Undecided" when reporting a new bug. The bug reporter could propose a priority in a comment. A dedicated bug triage team should set the initial priority for the bug while processing it as early as possible. Final priority setting would be decided by bug triage process. Priorities range from High (most important) to Low (least important).
* High: Bug fixing is on-going, or is planned within 2 weeks, no later than the up-coming milestone. Reproducible crash issues, major function loss, issues greatly impact user experience or issues which block other key features to work would fall in to this category.
* Medium: Bug fixing is planned before project release, but can't start before HIGH priority items are cleaned up.
* Low: Bug fixing is not planned for the up-coming project release. Will re-evaluate the importance in next release.

===Severity===

The "Severity" field describes the impact of a bug, and the options include:

* Critical: crashes, other components are affected
* Major: major loss of own function
* Normal: regular issue, some loss of functionality under specific circumstances
* Trival:cosmetic problem like misspelled words or misaligned text
* Enhancement: request for enhancement

==Platform==
===Hardware===

Please select the UX (like Netbook, Nettop, Notebook, Handset, Automotive, TV) that you identified the bug in.
For bugs which apply to all UX (like bugs for Middleware/Core components), please select "All".

===Architecture===

Please select the architecture (IA, ARM) that you identified the bug in. For example for N900 Base OS layer bugs this should be set to ARM.
For bugs which apply for multiple architectures, like bugs for middleware or applications, please select "All".

= Bug Life Cycle =
[[file:Bug-life-cycle-meego.PNG]]

= Bug Reporting/Follow-up Guideline =

1. Each bug report is for only one issue. If you find several issues in one test, please separate them into several bugs.

2. Write a precise summary (bug title). A good summary should be straightforward and precise, to clearly identify the issue. This also helps avoiding duplicate reports.

3. List the exact steps to reproduce the bug (bash commands, results after executing the commands etc, instead of only paraphrasing). For example, instead of paraphrasing commands by saying:
"suspend the system or put system to S3"
we prefer to see the following exact commands as steps to reproduce the bug:
echo mem >/sys/power/state

4. Describe the current outcome and the expected outcome. Try to avoid writing "See screenshot" or "See attached file" but describe it briefly in words so it can be found when querying for existing bug reports (this helps avoiding duplicate reports).

5. Reproducibility. For bugs which are not 100% reproducible, please provide an estimate of the probability of reproduction.

6. Impact to system or user. Provide a description of the actual impact to the system or user.

7. DO NOT reopen if same defect found again after more than 2 weeks. New bug report with “[REG]” as a prefix in the summary is mandatory.

8. NEEDINFO bugs should be assigned back to original bug reporter and NEEDINFO status should be removed after requested missing data has been provided in the report. NEEDINFO status should only be used for requests against the original bug reporter.

9. For "Target Milestone", when reports are in OPEN or RESOLVED status, it means to propose the bug to get fixed for a particular release; When verifying bugs, set the correct milestone where the bug is fixed.

= MeeGo update release bug fix management guideline =
Generally, the approved update release bugs must be fixed and verified in MeeGo Trunk firstly.
(1) With Bugzilla, an approved release update (eg 1.1) bug must have a MeeGo bug entry in the latest release (eg 1.2) so QA can verify the latest (eg 1.2) Trunk build has the same bug fix on a target vertical platform.
(2) With Bugzilla, an approved release update (eg 1.1) bug should have a bug in the latest release (eg 1.2) as a dependency (or blocker bug) to sure that the associated bug in the latest release is verified first.
(3) Update release engineer should _not_ accept development patch submission for update release unless QA verified in Trunk build and mark the Bugzilla entry accordingly.

Of course, there are some exceptions that don't apply this guideline especially for those bugs in old releases are not applicable to latest release. For example:
(1) Bug fixes in old releases' components where the latest release is using a different version;
(2) Components used in old releases that are no longer used in trunk;
(3) Security fixes that don't apply to the version in trunk, etc.

= Guidelines =
We like to have fun but we also like the communications to run smoothly. To that end here are some guidelines for participating in [https://bugs.meego.com Bugzilla].

==Do be patient with others==
We have both techies and non-techies here and we both know we don't exactly speak the same language at all times. In case of missing information kindly tell reporters how to provide it, and/or point to https://bugs.meego.com/page.cgi?id=bug-writing.html in case of very vague reports (like "Can't send mail, plz help!!").

==Do search before you file a bug==
Try to avoid filing duplicates by [http://bugs.meego.com/query.cgi taking a look] whether your issue has already been filed before.

==Keep it clean==
* Don't start endless debates on topics not directly related to the scope of a specific bug report, for example release engineering or marketing. We have [[Community communication|forums and mailing lists]] for that.
* Avoid quoting complete previous comments by stripping unneeded lines.
* Avoid answering above the quoted text.

==The admins Rule==
Ultimately, the admins reserve the right to block your account. See our [[Community guidelines|process for dealing with violations]] for more details.

= How to get involved =
As a non-coder you can get involved by [http://bugs.meego.com/enter_bug.cgi reporting bugs] and [http://wiki.meego.com/Quality/Bugtriage triaging bug reports].

File:Bug-life-cycle-meego.PNG

2010-11-04T01:09:32Z

Wanshuang:

Quality/How To Report Bugs

2010-11-04T01:09:01Z

Wanshuang: /* Bug Life Cycle */

Quality/TestSuite/handset-test-suite

2010-09-02T08:02:02Z

Wanshuang: /* Test Suite Design Progress */

== Test Suite Design Progress ==
Follow-up table for HandSet UX 1.1 Test Case creation progress.

* Planned Test: test cases are planned to be developed
* Actual Test - Designed: actual designed test cases
* Actual Test - Ready: test cases that are ready to run currently

{| border="1"
!
! Planned Test
! Actual Test - Designed
! Actual Test - Ready
! Automation %
! Test Suite Due
! Cross Review
! Test Suite Maintainer
! QA CCed
! Comments
|-
|Photo Viewer
|80
|42
|26
|0
|TBD
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Audio Player
|100
|73
|57
|0
|TBD
|Not Started
|Shuang Wan (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Video Player
|60
|20
|17
|0
|TBD
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Camera
|50
|44
|0
|0
|TBD
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Information Applets
|80
|73
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|Some of current applets test cases might be obsolete as Applet framework has been deprecated in MTF and will use WRT(Web Runtime Toolkit). No feature request or UI design for applets, and the feature might not be 1.1.
|-
|Contacts / Address Book
|150
|33
|116
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Email
|80
|24
|64
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Core UX
|150
|24
|106
|0
|End Of August except systemUI
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for system UI. System UI test cases are based on real implementation in current stage.
|-
|Settings
|130
|22
|18
|0
|TBD
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|We have got the feature request in WW35, test cases are under development now
|-
|VKB
|50
|23
|17
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Calendar
|70
|8
|87
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Social Networking
|60
|0
|9
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for social networking.
|-
|Data Sync
|0
|0
|0
|0
|TBD
|Not Started
|Qin Mu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Dialer
|60
|24
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|SMS
|40
|16
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|Browser
|100
|15
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Qin Mu (Intel)
|To be updated
|-
|Networking
|50
|10
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Dayu Yang (Intel)
|To be updated
|-
|Instant Messaging
|15
|21
|27
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|To be updated
|-
|VoIP
|N/A
|N/A
|N/A
|N/A
|TBD
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|VoIP has been removed from 1.1 content
|}

Quality/TestSuite/handset-test-suite

2010-09-02T08:00:42Z

Wanshuang: /* Test Suite Design Progress */

== Test Suite Design Progress ==
Follow-up table for HandSet UX 1.1 Test Case creation progress.

* Planned Test: test cases are planned to be developed
* Actual Test - Designed: actual designed test cases
* Actual Test - Ready: test cases that are ready to run currently

{| border="1"
!
! Planned Test
! Actual Test - Designed
! Actual Test - Ready
! Automation %
! Test Suite Due
! Cross Review
! Test Suite Maintainer
! QA CCed
! Comments
|-
|Photo Viewer
|80
|42
|26
|0
|End of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Audio Player
|100
|73
|57
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Video Player
|60
|20
|17
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Camera
|50
|44
|0
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Information Applets
|80
|73
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|Some of current applets test cases might be obsolete as Applet framework has been deprecated in MTF and will use WRT(Web Runtime Toolkit). No feature request or UI design for applets, and the feature might not be 1.1.
|-
|Contacts / Address Book
|150
|33
|116
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Email
|80
|24
|64
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Core UX
|150
|24
|106
|0
|End Of August except systemUI
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for system UI. System UI test cases are based on real implementation in current stage.
|-
|Settings
|130
|22
|18
|0
|TBD
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|We have got the feature request in WW35, test cases are under development now
|-
|VKB
|50
|23
|17
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Calendar
|70
|8
|87
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Social Networking
|60
|0
|9
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for social networking.
|-
|Data Sync
|0
|0
|0
|0
|TBD
|Not Started
|Qin Mu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Dialer
|60
|24
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|SMS
|40
|16
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|Browser
|100
|15
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Qin Mu (Intel)
|To be updated
|-
|Networking
|50
|10
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Dayu Yang (Intel)
|To be updated
|-
|Instant Messaging
|15
|21
|27
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|To be updated
|-
|VoIP
|N/A
|N/A
|N/A
|N/A
|TBD
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|VoIP has been removed from 1.1 content
|}

Quality/TestSuite/handset-test-suite

2010-08-26T13:15:29Z

Wanshuang: /* Test Suite Design Progress */

== Test Suite Design Progress ==
Follow-up table for HandSet UX 1.1 Test Case creation progress.

* Planned Test: test cases are planned to be developed
* Actual Test - Designed: actual designed test cases
* Actual Test - Ready: test cases that are ready to run currently

{| border="1"
!
! Planned Test
! Actual Test - Designed
! Actual Test - Ready
! Automation %
! Test Suite Due
! Cross Review
! Test Suite Maintainer
! QA CCed
! Comments
|-
|Photo Viewer
|150
|160
|75
|0
|End of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Audio Player
|150
|140
|60
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Video Player
|150
|122
|46
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Camera
|50
|44
|0
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Information Applets
|80
|73
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|Some of current applets test cases might be obsolete as Applet framework has been deprecated in MTF and will use WRT(Web Runtime Toolkit). No feature request or UI design for applets, and the feature might not be 1.1.
|-
|Contacts / Address Book
|150
|143
|105
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Email
|80
|24
|64
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Core UX
|150
|24
|96
|0
|End Of August except systemUI
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for system UI. System UI test cases are based on real implementation in current stage.
|-
|Settings
|130
|22
|18
|0
|TBD
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|We have got the feature request in WW35, test cases are under development now
|-
|VKB
|50
|23
|17
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Calendar
|70
|79
|70
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Social Networking
|60
|0
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for social networking.
|-
|Data Sync
|0
|0
|0
|0
|TBD
|Not Started
|Qin Mu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Dialer
|60
|24
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|SMS
|40
|16
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|Browser
|100
|15
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Qin Mu (Intel)
|To be updated
|-
|Networking
|50
|10
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Dayu Yang (Intel)
|To be updated
|-
|Instant Messaging
|15
|21
|27
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|To be updated
|-
|VoIP
|N/A
|N/A
|N/A
|N/A
|TBD
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|VoIP has been removed from 1.1 content
|}

Quality/TestSuite/handset-test-suite

2010-08-18T04:44:00Z

Wanshuang: /* Test Suite Design Progress */

== Test Suite Design Progress ==
Follow-up table for HandSet UX 1.1 Test Case creation progress.

* Planned Test: test cases are planned to be developed
* Actual Test - Designed: actual designed all test cases
* Actual Test - Ready: test cases that are ready to run currently

{| border="1"
!
! Planned Test
! Actual Test - Designed
! Actual Test - Ready
! Automation %
! Test Suite Due
! Cross Review
! Test Suite Maintainer
! QA CCed
! Comments
|-
|Photo Viewer
|150
|156
|62
|0
|End of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Audio Player
|150
|131
|45
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Video Player
|150
|122
|32
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Camera
|50
|44
|0
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Information Applets
|80
|73
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|Some of current applets test cases might be obsolete as Applet framework has been deprecated in MTF and will use WRT(Web Runtime Toolkit).
|-
|Contacts / Address Book
|150
|0
|73
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Email
|80
|72
|57
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Core UX
|180
|117
|93
|0
|End Of August except systemUI
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for system UI. System UI test cases are based on real implementation in current stage.
|-
|Settings
|130
|22
|18
|0
|TBD
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for Settings, the test cases ready are based on the settings application in current image
|-
|VKB
|50
|41
|16
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Calendar
|70
|50
|0
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Social Networking
|60
|0
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for social networking.
|-
|Data Sync
|0
|0
|0
|0
|End Of August
|Not Started
|Qin Mu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Dialer
|167
|157
|68
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|SMS
|95
|88
|49
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|Browser
|100
|15
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Qin Mu (Intel)
|To be updated
|-
|Networking
|50
|10
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Dayu Yang (Intel)
|To be updated
|-
|Instant Messaging
|15
|0
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|To be updated
|-
|VoIP
|N/A
|N/A
|N/A
|N/A
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|VoIP has been removed from 1.1 content
|}

Quality/TestSuite/handset-test-suite

2010-08-18T04:43:39Z

Wanshuang: /* Test Suite Design Progress */

== Test Suite Design Progress ==
Follow-up table for HandSet UX 1.1 Test Case creation progress.

* Planned Test: test cases are planned to be developed
* Actual Test - Designed: actual designed all test cases
* Actual Test - Ready: test cases that are ready to run currently

{| border="1"
!
! Planned Test
! Actual Test - Designed
! Actual Test - Ready
! Automation %
! Test Suite Due
! Cross Review
! Test Suite Maintainer
! QA CCed
! Comments
|-
|Photo Viewer
|150
|156
|62
|0
|End of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Audio Player
|150
|131
|45
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Video Player
|150
|122
|32
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Camera
|50
|44
|0
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|
|-
|Information Applets
|80
|73
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|Some of current applets test cases might be obsolete as Applet framework has been deprecated in MTF and will use WRT(Web Runtime Toolkit).
|-
|Contacts / Address Book
|150
|0
|73
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Email
|80
|72
|57
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Core UX
|180
|117
|93
|0
|End Of August except systemUI
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for system UI. System UI test cases are based on real implementation in current stage.
|-
|Settings
|130
|22
|18
|0
|TBD
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for Settings, the test cases ready are based on the settings application in current image
|-
|VKB
|50
|41
|16
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Calendar
|70
|50
|0
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Social Networking
|60
|0
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for social networking.
|-
|Data Sync
|0
|0
|0
|0
|End Of August
|Not Started
|Qin Mu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Dialer
|167
|157
|68
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|SMS
|95
|88
|49
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|Browser
|100
|15
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Qin Mu (Intel)
|To be updated
|-
|Networking
|50
|10
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Dayu Yang (Intel)
|To be updated
|-
|Instant Messaging
|15
|0
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|To be updated
|-
|VoIP
|N/A
|N/A
|N/A
|N/A
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|VoIP has been removed from 1.1 content
|}

Quality/TestSuite/handset-test-suite

2010-08-18T04:34:27Z

Wanshuang: /* Test Suite Design Progress */

== Test Suite Design Progress ==
Follow-up table for HandSet UX 1.1 Test Case creation progress.

* Planned Test: test cases are planned to be developed
* Actual Test - Designed: actual designed all test cases
* Actual Test - Ready: test cases that are ready to run currently

{| border="1"
!
! Planned Test
! Actual Test - Designed
! Actual Test - Ready
! Automation %
! Test Suite Due
! Cross Review
! Test Suite Maintainer
! QA CCed
! Comments
|-
|Photo Viewer
|150
|156
|62
|0
|End of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Audio Player
|150
|131
|45
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Video Player
|150
|122
|32
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Camera
|50
|44
|0
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|Camera application is not ready yet.
|-
|Information Applets
|80
|73
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|Some of current applets test cases might be obsolete as Applet framework has been deprecated in MTF and will use WRT(Web Runtime Toolkit).
|-
|Contacts / Address Book
|150
|0
|73
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Email
|80
|72
|57
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Core UX
|180
|117
|93
|0
|End Of August except systemUI
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for system UI. System UI test cases are based on real implementation in current stage.
|-
|Settings
|130
|22
|18
|0
|TBD
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for Settings, the test cases ready are based on the settings application in current image
|-
|VKB
|50
|41
|16
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Calendar
|70
|50
|0
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Social Networking
|60
|0
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for social networking.
|-
|Data Sync
|0
|0
|0
|0
|End Of August
|Not Started
|Qin Mu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Dialer
|167
|157
|68
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|SMS
|95
|88
|49
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|Browser
|100
|15
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Qin Mu (Intel)
|To be updated
|-
|Networking
|50
|10
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Dayu Yang (Intel)
|To be updated
|-
|Instant Messaging
|15
|0
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|To be updated
|-
|VoIP
|N/A
|N/A
|N/A
|N/A
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|VoIP has been removed from 1.1 content
|}

Quality/TestSuite/handset-test-suite

2010-08-18T04:32:46Z

Wanshuang: /* Test Suite Design Progress */

== Test Suite Design Progress ==
Follow-up table for HandSet UX 1.1 Test Case creation progress.

* Planned Test: test cases are planned to be developed
* Actual Test - Designed: actual designed all test cases
* Actual Test - Ready: test cases that are ready to run currently

{| border="1"
!
! Planned Test
! Actual Test - Designed
! Actual Test - Ready
! Automation %
! Test Suite Due
! Cross Review
! Test Suite Maintainer
! QA CCed
! Comments
|-
|Photo Viewer
|150
|156
|62
|0
|End of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Audio Player
|150
|131
|45
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Video Player
|150
|122
|32
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Camera
|50
|44
|0
|0
|End Of August
|Not Started
|Shuang Wan (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Information Applets
|80
|73
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|Some of current applets test cases might be obsolete as Applet framework has been deprecated in MTF and will use WRT(Web Runtime Toolkit).
|-
|Contacts / Address Book
|150
|0
|73
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Kalle Kyllönen (Nokia)
|To be updated
|-
|Email
|80
|72
|57
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Core UX
|180
|117
|93
|0
|End Of August except systemUI
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for system UI. System UI test cases are based on real implementation in current stage.
|-
|Settings
|130
|22
|18
|0
|TBD
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for Settings, the test cases ready are based on the settings application in current image
|-
|VKB
|50
|41
|16
|0
|End Of August
|Not Started
|Yi Fu (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Calendar
|70
|50
|0
|0
|End Of August
|Not Started
|Dayu Yang (Intel)
|Juha Paukku (Nokia)
|To be updated
|-
|Social Networking
|60
|0
|0
|0
|TBD
|Not Started
|Cathy Li (Intel)
|Juha Paukku (Nokia)
|No feature request or UI design doc for social networking.
|-
|Data Sync
|0
|0
|0
|0
|End Of August
|Not Started
|Qin Mu (Intel)
|Mika Ikonen (Nokia)
|To be updated
|-
|Dialer
|167
|157
|68
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|SMS
|95
|88
|49
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Lily (Intel)
|To be updated
|-
|Browser
|100
|15
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Qin Mu (Intel)
|To be updated
|-
|Networking
|50
|10
|0
|0
|End Of August
|Not Started
|Petri Jylhä (Nokia)
|Dayu Yang (Intel)
|To be updated
|-
|Instant Messaging
|15
|0
|0
|0
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|To be updated
|-
|VoIP
|N/A
|N/A
|N/A
|N/A
|End Of August
|Not Started
|Mika Ikonen (Nokia)
|Yi Fu (Intel)
|VoIP has been removed from 1.1 content
|}

MeeGo Bugzilla customization

2010-06-07T08:35:53Z

Wanshuang:

Totally applied about 10 items to MeeGo Bugzilla to meet the MeeGo bug managment requirements.

=== Support Drupal user authentication system ===
* MeeGo bugzilla share the same user DB in meego.com, so there is no need to ask user to register multiple accounts
=== Copy right waiver flag for attachment ===
* User is able to choice copyright waiver option when submit a patch
=== Control who can change and set bug's priority ===
=== Bug vote option ===
* User is able to vote the bug, vote number indicates how many peoples care specific bug
=== Optimized the new bug navigation web page ===
* Expand the classification MeeGo Platform in classification selection page, and list products within it. User is able to choice the product under this classification directly. This reduced one step when file new bug to most comm used classification MeeGo Platform.
=== Use customized flag to manage release blocker bugs ===
* Normal user can propose blocker bugs;
* Users in CCB can approve/reject blocker bugs;
=== Customized Bugzilla new bug template for product MeeGo Platform ===
=== Set the default value for clone bug ===
=== Security flag ===
* Added one checkbox to indentify bug's security property;
=== Security product ===
* The bugs in security product can be seen only to Security group, bug reporter and user in bug cc list.

MeeGo Bugzilla customization

2010-06-07T08:31:57Z

Wanshuang:

Totally applied about 10 items to MeeGo Bugzilla to meet the MeeGo bug managment requirements.

=== 1. Support Drupal user authentication system ===
* MeeGo bugzilla share the same user DB in meego.com, so there is no need to ask user to register multiple accounts
=== 2. Copy right waiver flag for attachment ===
* User is able to choice copyright waiver option when submit a patch
=== 3. Control who can change and set bug's priority ===
=== 4. Enabled bug vote option ===
* User is able to vote the bug, vote number indicates how many peoples care specific bug
=== 5. Optimized the new bug navigation web page ===
* Expand the classification MeeGo Platform in classification selection page, and list products within it. User is able to choice the product under this classification directly. This reduced one step when file new bug to most comm used classification MeeGo Platform.
=== 6. Use customized flag to manage release blocker bugs ===
* Normal user can propose blocker bugs;
* Users in CCB can approve/reject blocker bugs;
=== 7. Customized Bugzilla new bug template for product MeeGo Platform ===
=== 8. Set the default value for clone bug ===
=== 9. Security flag ===
* Added one checkbox to indentify bug's security property;
=== 10. Security product ===
* The bugs in security product can be seen only to Security group, bug reporter and user in bug cc list.

MeeGo Bugzilla customization

2010-06-07T08:30:48Z

Wanshuang:

Totally applied about 10 items to MeeGo Bugzilla to meet the MeeGo bug managment requirements.

=== 1. Support Drupal user authentication system ===
* MeeGo bugzilla share the same user DB in meego.com, so there is no need to ask user to register multiple accounts
=== 2. Copy right waiver flag for attachment ===
* User is able to choice copyright waiver option when submit a patch
=== 3. Control who can change and set bug's priority ===
=== 4. Enabled bug vote option ===
* User is able to vote the bug, vote number indicates how many peoples care specific bug
=== 5. Optimized the new bug navigation web page ===
* Expand the classification MeeGo Platform in classification selection page, and list products within it. User is able to choice the product under this classification directly. This reduced one step when file new bug to most comm used classification MeeGo Platform.
=== Use customized flag to manage release blocker bugs ===
Normal user can propose blocker bugs;
Users in CCB can approve/reject blocker bugs;

=== Customized Bugzilla new bug template for product MeeGo Platform ===

=== Set the default value for clone bug ===

=== Security flag ===
Added one checkbox to indentify bug's security property;

=== Security product ===
The bugs in security product can be seen only to Security group, bug reporter and user in bug cc list.

MeeGo Bugzilla customization

2010-06-07T08:27:38Z

Wanshuang: Created page with 'Totally applied about 11 items to MeeGo Bugzilla to meet the MeeGo bug managment requirements. === Support Drupal user authentication system === MeeGo bugzilla share the same…'

Totally applied about 11 items to MeeGo Bugzilla to meet the MeeGo bug managment requirements.

=== Support Drupal user authentication system ===
MeeGo bugzilla share the same user DB in meego.com, so there is no need to ask user to register multiple accounts

=== Copy right waiver flag for attachment ===
User is able to choice copyright waiver option when submit a patch

=== Control who can change and set bug's priority ===

=== Enabled bug vote option ===
User is able to vote the bug, vote number indicates how many peoples care specific bug

=== Optimized the new bug navigation web page ===
Expand the classification MeeGo Platform in classification selection page, and list products within it. User is able to choice the product under this classification directly.
This reduced one step when file new bug to most comm used classification MeeGo Platform.

=== Use customized flag to manage release blocker bugs ===
Normal user can propose blocker bugs;
Users in CCB can approve/reject blocker bugs;

=== Customized Bugzilla new bug template for product MeeGo Platform ===

=== Set the default value for clone bug ===

=== Security flag ===
Added one checkbox to indentify bug's security property;

=== Security product ===
The bugs in security product can be seen only to Security group, bug reporter and user in bug cc list.