Account confirmers, Anti-spam team, canmove, Confirmed users, Bureaucrats and Sysops emeriti
4,083
edits
User:KaiRo/Filing Crash Bugs: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 17: | Line 17: | ||
* Examples of good crash bug reports: {{bug|1035168}} | * Examples of good crash bug reports: {{bug|1035168}} | ||
== Example walkthrough | == Example walkthrough == | ||
Let's take {{bug|1074196}} as an example again as I mentioned it before. As mentioned at the start of the initial comment, I filed it from this crash report: https://crash-stats.mozilla.com/report/index/fd16294d-0bbf-4530-b2d4-65c2d2140929. This specific crash report expires 6 months after it was submitted and some info is only shown for a shorter time, so you might not see exactly the same as I did. | Let's take {{bug|1074196}} as an example again as I mentioned it before. As mentioned at the start of the initial comment, I filed it from this crash report: https://crash-stats.mozilla.com/report/index/fd16294d-0bbf-4530-b2d4-65c2d2140929. This specific crash report expires 6 months after it was submitted and some info is only shown for a shorter time, so you might not see exactly the same as I did. | ||
| Line 27: | Line 27: | ||
Looking through those, I try to find properties that fall out of the ordinary (like only few Product versions being listed in the "Products" section, only very specific OSes listed, or specific graphics adapters, or much fewer installations than crashes listed in "Crashes per Install"), and looking at the list in the "Reports" tab, some things like the same address on all reports are interesting as well. All those should be listed in a comment on the bug report. | Looking through those, I try to find properties that fall out of the ordinary (like only few Product versions being listed in the "Products" section, only very specific OSes listed, or specific graphics adapters, or much fewer installations than crashes listed in "Crashes per Install"), and looking at the list in the "Reports" tab, some things like the same address on all reports are interesting as well. All those should be listed in a comment on the bug report. | ||
Explaining the full hierarchy is not really possible, and it changes all the time in terms of components being added, some also retired. But I can give you a few pointers to the cornerstones, so to speak. Note that all this has grown organically over the 15+ years that the Mozilla project and Bugzilla have exited now, so some things might not be the same as one would design from scratch. | |||
== Understanding the Bugzilla hierarchy == | |||
The most important pieces: | |||
1) There's Bugzilla "products" for, logically, the major products we have at Mozilla, like Firefox, Firefox for Android, Firefox OS, Thunderbird, SeaMonkey, etc. - those are *only* about things that are specific to that one product and not in code that multiple of those products share. | |||
2) For shared code, there's the "Core" product, which has all the underpinnings of Gecko and "the Mozilla platform", like Grpahics, Javascript Engine, networking, etc. - and there's "Toolkit" for some other shared code that is closer to or including user interface pieces, like Add-ons Manager, and some other pieces. The difference between those parts is fluid and many of us often don't know what is in which of those two, you have to search and learn here. | |||
3) There are a lot of supporting "products" like for websites and server software, legal issues, localizations, IT operations, 3rd-party plugins, etc. - you can ignore them most of the time, but sometimes you might get directed to one for something. Best is to not try to understand more of those than what you run across and need for a certain task. | |||
4) All those "products" in Bugzilla have "components" underneath them. When filing a bug in Bugzilla, once you have selected a product, there's a description of the component displayed when you select one from the list. Try to use your best guess from those descriptions of where your bugs fits. It's easy to change afterwards and we put bugs into "wrong" components all the time as well as for some things it's just hard to figure out or lines are blurry. Don't shy away from setting one, it's easy to move to a different one afterwards if you guess wrong. | |||
The general rule here like with many other things in our community is: Guess and try to do what makes most sense for you, nobody will think less of you if you guess wrong. Be bold and try what sounds the best way for you and learn as you go. It's better to try and learn than not to try in the first place. | |||