Firefox OS এর বাগ রিপোর্ট করা

এই নিবন্ধে গায়া, বিটুজি এবং Firefox OS প্রজেক্ট এর বাগ রিপোর্ট সম্পর্কে নির্দেশনা দেয়া হয়েছে।


As with most projects in Mozilla, we use Bugzilla for bug and issue status tracking. You can file bugs to bugzilla when you found bugs — we have a separate product for Firefox OS, which contains components for topics falling under Gaia, Gonk and Firefox OS Gecko. You should use this component to file bugs against Firefox OS, B2G, Gaia, etc.

Note: The Mozilla B2G QA Wiki page also has some useful resources on handling Firefox OS bugs; the most useful pages are Bugzilla Usage and Incoming bug triage for Firefox OS.

বাগ ফাইল করা

To file an effective bug, you can follow the instructions at Bug writing guidelines; you'll also find further details below.

আবশ্যিক এবং ঐচ্ছিক ফিল্ড

When filing a new bug, some fields are mandatory:

ফিল্ড বর্ণনা
Component Choose the category the bug should belong to. If you have no idea which category the issue should be, You can put it in "General".
Summary Give a summary to briefly describe the bug.
Description Describe the situation clearly. A good bug should contain: STR (Steps to reproduce), Expected Result, Actual Result, and Version number. A version number can be either a Gaia/Gecko commit or a Build ID (available from pvt build servers or public versions).

The following fields are optional:

ফিল্ড বর্ণনা
Attachment Any attachment that can help to analyse the bug. Videos, pictures, testcases or logs are good for analyzing.
Depends/Block Show the dependency between bugs.
Keywords Keywords for bugzilla. Specific groups will use it for tracking.
Whiteboard Contains tags. Add any tag to it for tracking. You shouldn't remove others' tags without permission.
See Also Sometimes, two issues are related and you can specify this here.
Flags Flags for tracking status; the most used flag in Firefox OS bugs is blocking-b2g. If a bug is set as blocking-b2g, it means we should pay more attention to it as it threatens to block a release.
Security If a bug is related to personal data security, loss of earnings, and other such issues, you should check the checkbox and it will only be visiable to involved employees.

To find more information on bugzilla fields, you can view the Bugzilla Fields page on Bugzilla.

সাধারণ কীওয়ার্ড

The following table provide information on common keywords you'll see used in Firefox OS bugs.

কীওয়ার্ড বর্ণনা
meta Indicates that the bug is a status tracking bug. Mozilla uses this tag to tracking multiple bug or user story implementation statuses. Once marked like this, developers should not land patches on top of such bugs. Please be reminded that project managers and QA staff will use meta bugs for tracking.
qablocker Use this keyword for bugs that are blocking testing (manual or automated testing of a feature) and need to be fixed by the next Beta or RC milestone.
qawanted Use this keyword for bugs that need more info, require reproducing or testcasing, or are duplicates (but you can't find the original bug being duplicated). Required QA work progress is recorded in the whiteboard; you should remove this keyword when the required QA work has been completed.
regression This keyword means that the problem was fixed, but then it came back (regressed) and the bug in question is a new bug, filed to track the regression. It can also refer to problems outside those identified in pre-check in and smoke tests, which were found in current builds and that were known to be working in previous builds. Tracking these bugs helps us to identify areas that are fragile, prone to breakage and are good candidates for adding to smoke and pre-check in tests.
regressionwindow-wanted Indicates that the bug is a regression, and would strongly benefit from someone identifying the time period in which it happened, ideally to a specific check in.
steps-wanted Highlights a bug that would greatly benefit from someone identifying the steps to reproduce it.
verifyme Means that this bug is ok to verify with the latest B2G build by someone other than the QA Contact indicated. The bug has specific machine configuration details indicated for verifying the fix. You should try to reproduce the failure, and, if you agree that the resolution of Fixed is correct, mark the Status as Verified.

You should always indicate the build/OS/platform(s) used to verify the bug in the bug comments, before you change the Status to Verified. If the bug is reported on all three platforms and you only have one platform to verify the fix on, go ahead and do so and note it in the bug, but do not mark the bug as Verified. All platforms must be checked before moving Status to Verified.

Finally, if other bugs have been marked as a duplicate of the bug you're verifying, be sure to check and mention those as well. Often developers mark related — but not identical — bugs as duplicates, and these can be overlooked if not checked.

নোট: For more information on handling bugs during Gaia development, read Submitting a Gaia patch.