Confirmed users
48
edits
(new FAQ page for Bugdays) |
m (added heading to each question so to have an easy linking structure) |
||
Line 1: | Line 1: | ||
=== General === | === General === | ||
===== How do I find the build ID of Nightly? ===== | |||
There are various methods: you can check in Help → About Nightly; or you can open the page about:healthreport, click on Raw Data and search for "appBuildID". Or you can use an add-on like Nightly Tester Tools, which include various useful tools for the tester. Without running the Nightly, you can find the details in some lines of the application.ini file. If you download a Nightly using mozdownload, the file name will contain the build ID and the OS. | |||
=== On Triaging === | === On Triaging === | ||
===== Do I need to reproduce a bug on the very same architecture/OS against which it's reported? ===== | |||
Yes, preferably. On the other hand, if you are able to reproduce it a different platform this may mean that the bug it's not platform dependent and you should add this information to the bug report in a comment, specifying: | |||
* Firefox version and build ID where you manage to reproduce it | * Firefox version and build ID where you manage to reproduce it | ||
Line 13: | Line 16: | ||
* If you have editbugs set the Platform/OS to All/All | * If you have editbugs set the Platform/OS to All/All | ||
===== How can I tag e10s related bugs so that they show up for the e10s team? (As for now there's no e10s component) ===== | |||
You can add the "tracking-e10s-?" status flag: it will then be looked at by the relevant team during meeting/triage. Another (maybe better?), option is to put "[e10s]" into the Whiteboard. | |||
===== How can I choose who to ask more info about a bug or a feature in a specific component? ===== | |||
Confirming the bug will put it in the developers attention and they will decide then if solve it as invalid (if that's the case). You can also perform a bugzilla query for that specific component and add one of the developers in the cc list of the bug, asking him/her their opinion. You can also check this [[Modules/All|list of Modules and their Owners]]. | |||
===== What do the different colors on a list of bug reports mean in Bugzilla? ===== | |||
Colors are related to the severity of the bug: red is for critical (crash or hangs bugs), gray is for enhancement. | |||
=== On Verification === | === On Verification === | ||
===== Do I need to verify a fix on the same arch/OS against which it's been reported? ===== | |||
Yes, if the platform field on Bugzilla is set to a specific arch/OS. If you can reproduce the bug in the known broken version on another platform then feel free to verify it as well on that platform and add your results in a comment. | |||
===== Do I need to verify the fix on all three channels (Beta, Aurora, Nightly)? ===== | |||
You usually have to just verify it against the version tagged as "fixed": look at the "Tracking flags" field. Here's the developers register which version is affected, fixed and or verified. For instance: | |||
status-firefox29: affected<br /> | status-firefox29: affected<br /> | ||
Line 39: | Line 47: | ||
===== Can I set the fxN → affected flag if I find that version N is still affected by the issue? ===== | |||
Yes. That flag means that a version is affected. If you can change the status flags, that can be useful for QA, for developers, and for release coordinators. | |||
===== How long before a patch arrives in Aurora, if not applied directly to that tree? ===== | |||
Six weeks | |||
' | ===== I have verified the fix of a bug on my platform, but it's filed against All/All. Can I mark it as Verified → Fixed, even if I didn't check the other platforms? ===== | ||
No: in order to mark it as Verified → Fixed you have to check it against at least 2 out of the 3 platforms (Linux, Mac, Windows). Just add your results on a comment. | |||