First draft for Bugdays' FAQ
Q: How do I find the build ID of Nightly?
A: 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". The about:support page also contains the build ID. Or you can use an add-on like Nightly Tester Tools, which include various useful tools for the tester. Without running 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.
Q: Do I need to reproduce a bug on the very same architecture/OS against which it's reported?
A: Yes, preferably. On the other hand, if you are able to reproduce it a different platform this may mean that the bug is not platform dependent and you should add this information to the bug report in a comment, specifying:
- Firefox version and build ID where you reproduced the bug
- Architecture and OS of the system where you reproduced the bug
- If you have editbugs, set the Platform/OS to All/All
Q: How can I tag e10s related bugs so that they show up for the e10s team? (As for now there's no e10s component)
A: 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 field.
Q: How can I choose who to ask more info about a bug or a feature in a specific component?
A: Confirming the bug may bring it to the developers attention, and they may decide that it needs work, or resolve it as invalid or wontfix. 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 list of Modules and their Owners.
Q: What do the different colors on a list of bug reports mean in Bugzilla?
A: Colors are related to the severity of the bug: red is for critical (crash or hangs bugs), gray is for enhancement.
Q: Do I need to verify a fix on the same arch/OS against which it's been reported?
A: 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.
Q: Do I need to verify the fix on all three channels (Beta, Aurora, Nightly)?
A: 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:
In this case, the bug was present on all three versions (29, 30, 31) and it has been fixed on 30 and 31. The latter has been already verified, while 30 is still in need of verification. We cannot verify it on 29 because the bug is still there and has not been fixed in that version. Your job will be to verify the fix on 30, and then register your results. If you have "editbugs" permission, you can also change the tracking flag for 30 from fixed to verified.
Q: Can I set the fxN → affected flag if I find that version N is still affected by the issue?
A: 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.
Q: How long before a patch arrives in Aurora, if not applied directly to that tree?
A: Six weeks
Q: 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?
A: 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.