QA:Bugzilla:FAQ

From Camino Wiki
Jump to: navigation, search

What to do with a bug or feature request

If you want your bug or feature request to be considered, it’s important to follow the right process. Doing so ensures that it will be seen and considered by the Camino developers.

Q. I found a bug. What should I do?

A. Bugs for Camino are managed through a system called Bugzilla. To report a bug, just go to the <a href="https://bugzilla.mozilla.org/enter_bug.cgi?format=guided&product=Camino">bug reporting helper</a> and follow the instructions. Be sure to take the time to search for duplicates in step 1, since repeated reports of the same issue waste both your and developers’ time.

If you’ve never used the system before, you’ll need to <a href="https://bugzilla.mozilla.org/createaccount.cgi">create an account</a> first. Creating an account is extremely quick and easy.

Q. Camino crashed! What do I do now?

A. If you can reproduce the crash, file a bug. When reporting a crashing bug, be sure to set the severity to “critical”, add “crash” in the keyword field, and have the following things handy: the URL on which the crash occurred (if the crash was browsing-related), detailed steps to reproduce the crash (if some action was required), and a crash log.

Mac OS X ships with a very helpful tool called Crash Reporter. When Camino crashes and you see a dialog stating “The application Camino has unexpectedly quit”, click the Submit Report… button. Copy the entire contents of the “Crash Report:” text field into a new plain-text document (in TextEdit, create a new document and choose Make Plain Text from the Format menu). Once you have saved the text file, you can dismiss the Crash Report dialog. Note: The wording of the dialogs varies slightly between major Mac OS X versions.

If the “The application Camino has unexpectedly quit” dialog fails to appear, you have most likely disabled Crash Reporter and you will have to extract the crash log from the system’s crash logs manually.

After you have filed your initial bug report, attach the file containing the crash log to the bug using the “Create a New Attachment” link. Please do not paste crash reports into the “Comments” field of the bug report.

In addition to taking these steps to obtain the crash report, you should let the <a href="/documentation/faq/#troub_talkback">Talkback</a> application run and file a report with mozilla.org; this report is used to aggregate crash data and often helps identify causes of crashes that are otherwise not reproducible.

Q. Camino keeps displaying the “spinning beachball” and does not respond.

A. Camino has entered a “hung” state; the only way to end this state is to “force quit” Camino. If you can reproduce the situation, file a bug. Be sure to set the severity to “critical”, add “hang” in the keyword field, and have the following things handy: the URL on which the hang occurred (if the hang was browsing-related), detailed steps to reproduce the hang (if some action was required), and a sample of Camino while it is in the hung state.

Before you force quit Camino, open the Activity Monitor application located in the Utilities subfolder of the Applications folder. On launch, the application should display a window listing various “processes” that are running on your Mac. Select Camino from the list and then click the Inspect button. In the window that opens, click the Sample button; this will generate a log that will help the developers determine why Camino entered the hung state. When the sample is complete, save the file; you may now close the sample window and force quit Camino.

After you have filed your initial bug report, attach the sample file to the bug using the “Create a New Attachment” link. Please do not paste samples into the “Comments” field of the bug report.

Q. There’s a problem with a page that requires a login.

A. In most cases the Camino developers and bug triage team members won’t have access to the site in question. However, there are still ways to generate a bug report that will allow the Camino team to assess the problem and hopefully fix it. When you are on the problematic page, take a screenshot (be sure to obscure any personal or confidential information before attaching the screenshot to your bug); a screenshot is most useful for situations where the page does not display properly.

After taking a screenshot, choose Save As… from the File menu and then select HTML Complete from the Format: drop-down menu at the bottom of the Save dialog. This will save a copy of the page and a folder containing all of the files referenced by that page (if the page is saved as my_page.html, the folder will be called my_page Files). If the page displayed any personal or confidential information (like a password or an account number), drag the saved .html file onto TextEdit and replace that information with a string of X or other characters. Be careful not to edit any of the HTML. It’s probably a good idea to check all of the associated files in the folder to make sure none of them contain personal information, either.

When you’re sure there’s no personal information remaining, select both the folder and the .html file in the Finder, ctrl-click, and choose Create Archive of 2 items from the Finder’s context menu. After you file your bug report, attach this archive and the screenshot (if needed) to the bug using the “Create a New Attachment” link. Make sure to include the URL to the page (again, removing any personal information that might be contained in the URL) in your bug report for reference.

Q. I want a new feature. What should I do?

A. Follow the instructions above for reporting a bug, but pick “Enhancement” as the severity at the last step.

Q. Can’t I just post a message about the bug/feature in the forum instead?

A. You could, but it’s extremely unlikely to be fixed if you don’t file a bug. Developers use Bugzilla to track everything that needs to be done, and anything that isn’t in that system can easily be forgotten. There’s no guarantee a forum post will even be seen by a developer.

Q. Why hasn’t my bug been fixed yet?

A. Camino is developed entirely by a small group of volunteers, working in their free time. Limited developer time means that some bugs and feature requests can wait for months, or even years, until someone has time to address them. The order bugs are fixed in depends on overall project priorities, as well as the difficulty of bugs and the skills and interests of individual developers. Do not complain in a bug or ask why it hasn’t been fixed yet—see the <a href="http://bugzilla.mozilla.org/page.cgi?id=etiquette.html">Bugzilla etiquette</a>. The only way to get bugs fixed faster is to contribute in some way (such as fixing them yourself, helping to recruit new developers, or helping out in some other way that frees up developers to spend more time on coding).

Demanding that a bug be fixed, whining, threatening to switch browsers, etc., is always counter-productive. Fixing bugs is simply a question of manpower and complaining in a bug wastes the time of everyone reading bug reports or following the progress of a bug via email.

Q. Why was my bug marked WONTFIX?

A. Camino’s goal is to be lightweight and easy to use. That means that it can’t include every feature that is ever requested. Invariably, some people will be unhappy with the decisions that are made regarding which features aren’t included, but strong leadership is necessary to keep Camino true to its vision. WONTFIX decisions are made by the Camino lead, are made for good reason (even if not explained in the bug), and as such are final. Do not complain or argue in a bug that has been marked WONTFIX. Unless you have new, compelling information to add, do not comment in the bug. Please remember that “x people I talked to said this is really important” is not compelling information. Unless you have have done a statistically valid sample of Camino’s entire target user base (and neither Bugzilla nor online forums are representative samples), you aren’t going to convince anyone.

Q. If only some people want a feature, couldn’t it just be a preference?

A. In general, no. First, every piece of code needs to be written and maintained, both of which take developer time away from bugs and other features. Second, each added preference makes all other preferences slightly less accessible. Camino’s goal is to be lightweight, which means keeping the number of preferences down as well.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox