289
edits
QA/Community/QMO Bugzilla/Documentation: Difference between revisions
Jump to navigation
Jump to search
QA/Community/QMO Bugzilla/Documentation (view source)
Revision as of 08:09, 8 September 2008
, 8 September 2008→More about mapping
| Line 49: | Line 49: | ||
=== More about mapping === | === More about mapping === | ||
Feedback shows this is the hardest feature for people to understand. Admittedly it takes a learning curve to get it, but here are the basics: | |||
* The backend - the XML | |||
** The module will look at an XML document. This XML document has a tree structure. Each bug is contained within a BZ:BUG tag, with its fields: BZ:ID, BZ:BUG_SEVERITY, etc. Bugs are parsed one by one and counted. | |||
** The parser only looks at the ID tag (which is stored so you can see which bugs matched what you wanted), and any additional columns you specify in the "Mapping" textarea. So, if you want to separate these bugs by severity, you put in BZ:BUG_SEVERITY as a column on the first row in the textarea. | |||
* The mapping process | |||
** Basically, it means mapping a sequence of values to a specific label. A many-to-one function. For example, if you want to map bugs to specific Mozilla Teams by Product and Component values: say, Layout belongs to the Gfx Team, JS Engine to the webdev team (I might be wrong on this). To do this, you look at the combination of values for the Product and Component fields and decide where it falls based on that. "Where it falls" is the label you give it, the function value, and Product and Component are the function parameters. That's how mapping works too. | |||
** Formatting: After you used the first row to specify the columns you want to look at for bugs, you can use the 2nd, 3rd (and on) rows to group bugs. The first row that matches over all specified columns will count. For each bug, the parser goes through the mapping and looks at the combination of column values. | |||
Below are examples, some are taken from the [[QA/Community/QMO_Bugzilla#Bugzilla_feedback]] page. These use the "best practices" described below in 'About the "Mapping" textarea'. | |||
1) # of fixed bugs over last week, by component, only for the Firefox product. | |||
Option 1 (preferred): | |||
BZ:COMPONENT | |||
* Umatched values: Show each as distinct. | |||
* Query gets only fixed bugs for the Firefox product over last week | |||
Option 2 (less efficient): | |||
BZ:PRODUCT|BZ:RESOLUTION|BZ:COMPONENT | |||
Firefox|Fixed|JavaScript Engine|JS Engine | |||
Firefox|Fixed|Add-ons|Add-ons | |||
... | |||
Firefox|Fixed|Layout|Layout | |||
* Umatched values: Don't show. | |||
* Query gets all bugs over last week | |||
2) # of blocker bugs by component over last week | |||
BZ:COMPONENT | |||
(empty from 2nd row on) | |||
* Umatched values: Show each as distinct | |||
* Query gets only blocker bugs. | |||
3) # of blocker bugs by product AND component over last week | |||
BZ:PRODUCT|BZ:COMPONENT | |||
(empty from 2nd row on) | |||
* Umatched values: Show each as distinct | |||
* Query gets only blocker bugs. | |||
4) # of bugs over grouped BZ:PRODUCT|BZ:COMPONENT combinations | |||
BZ:PRODUCT|BZ:COMPONENT | |||
Core|Layout*|Gfx team | |||
Firefox|CSS Styles|Gfx team | |||
Firefox|JavaScript Engine|JS bugs | |||
... (any other combination of the two)| (any label). | |||
The two Core+Layout* and Firefox+CSS Styles will add up for the Gfx team label, so you can group multiple values to the same value. | |||
* Umatched values: Don't show. | |||
* Query gets all bugs over last week | |||
For the above (and in general when using mapping): | |||
* Show total: NO (uncheck box) | |||
* The query URL used will contain the bugs filed within the last week (-7d) and its frequency will be weekly. (0000-00-07 00:00:00) | |||
==== Fields ==== | ==== Fields ==== | ||
* Map tag values = enable/disable mapping | * Map tag values = enable/disable mapping | ||