Are you here because you have a problem with Netscape Browser? If so, you're in the wrong place. Try visiting their technical support site or use the Netscape bug reporting form instead.
Are you here because you have a problem with a Debian branded product? If so, you're in the wrong place. Try visiting their technical support site or use their bug tracking system instead.
Do you want to report a bug with one of our milestone or nightly builds or with a copy of Mozilla that you compiled yourself? Bugzilla is the place to submit bug reports for software distributed by mozilla.org. This page gives an overview of how Bugzilla works. Read the bug writing guidelines as well, for tips on how to write useful bug reports.
Bugzilla is a database for bugs. It lets people report bugs and assigns these bugs to the appropriate developers. Developers can use Bugzilla to keep a to-do list as well as to prioritize, schedule and track dependencies.
Not all 'bugs' are bugs. Some items in the database are known as Enhancement Requests or Requests For Enhancement (RFE). An RFE is a bug whose severity field is set to 'enhancement'. People often say 'bug' when they mean 'item in Bugzilla', so RFEs often wind up being called bugs.
Enter the tasks you're planning to work on as enhancement requests and Bugzilla will help you track them and allow others to see what you plan to work on. If people can see your flight plan, they can avoid duplicating your work and can possibly help out or offer feedback.
Looking for the source of Bugzilla? If you want to set up a Bugzilla on your own server, you can get it here.
Bugs and RFEs are composed of many fields. Some of them are described here.
keywords.
For instance, the BugAThon
uses it to to note when bugs have test cases (using the keyword
testcase).
helpwantedDevelopers can use this field for posting
helpwanted notices. Write helpwanted in
the Keywords field of one of your bugs or RFEs and
others searching for things to do will find it. People interested
in getting involved can search
Bugzilla for bugs and RFEs marked
helpwanted. Maybe one of them will have the expertise
and resources to help you with your problem.
For instance, if your code has a bug on some platform which you don't have access to, or with some language you don't know, try adding this keyword.
Or, as with any developer, you're probably swamped with bugs.
Some of these bugs will be lower priority than others. Try marking
bugs that you realize you won't be able to any time soon as
helpwanted. Someone else with different priorities may
see this and help you out.
When marking bugs (or RFEs)
helpwanted, be sure to add a comment carefully
explaining what work needs to be done, and how to do it, if you
know. The better you can explain the problem and its solution, the
more likely it is that someone can provide a useful solution.
mozilla1.3, it
means an assigned developer picked Mozilla 1.3 as his/her estimate
of the earliest milestone at which that bug might be resolved. This
field should only be set by the person responsible for the
bug.What happens to a bug when it is first reported depends on who
reported it. New Bugzilla accounts by default create bugs which are
UNCONFIRMED - this means that a QA
(Quality Assurance) person needs to look at it and confirm it
exists before it gets turned into a NEW bug.
If you have been working in Bugzilla for a while and believe you
are worthy of being able to create NEW bugs, mail
Gerv.
When a bug becomes NEW, the developer will probably
look at the bug and either accept it or give it to someone else. If
the bug remains new and inactive for more than a week, Bugzilla
nags the bug's owner with email until action is taken. Whenever a
bug is reassigned or has its component changed, its status is set
back to NEW. The NEW status means that
the bug is newly added to a particular developer's plate, not that
the bug is newly reported.
Those to whom additional permissions have been given have the ability to change all the fields of a bug (by default, you can only change a few). Whenever you change a field in a bug it's a good idea to add additional comments to explain what you are doing and why. Make a note whenever you do things like change the component, reassign the bug, create an attachment, add a dependency or add someone to the CC list. Whenever someone makes a change to the bug or adds a comment, the owner, reporter, the CC list and those who voted for the bug are sent an email (unless they have switched it off) showing the changes to the bug report.
If you are doing much work in Bugzilla, you might want to check out the QA Help Page, which has various useful resources and things to do.
When a bug is closed it's marked RESOLVED and given
one of the following resolutions.
FIXEDFIXED.INVALIDWONTFIXDUPLICATEWORKSFORMEQA (this could be you -
check out the QA help
page) looks at resolved bugs and ensures the appropriate action
has been taken. If they agree, the bug is marked
VERIFIED. Bugs remain in this state until the product
ships, at which time the bug is marked CLOSED. Bugs
may come back to life by becoming REOPENED.
Be careful when changing the status of someone else's bugs. Instead of making the change yourself, it's usually best to make a note of your proposed change as a comment and to let the bug's owner review this and make the change themselves. For instance, if you think one bug is a duplicate of another, make a note of it in the 'Additional Comments' section.
If you make a lot of useful comments to someone's bugs they may come to trust your judgement and ask you to go ahead and make the changes yourself, but unless they do, it's best to be cautious and only make comments.
Bugzilla is open source software. Its source code has been released under the Mozilla Public License. Check out the Bugzilla website if you would like to use the Bugzilla source to create a bug system for your own project.