Bugzilla:FAQ:General Questions: Difference between revisions
m (→How can Bugzilla be made to work under SELinux?: category|F) |
(+Link to landfill) |
||
| Line 1: | Line 1: | ||
=General Questions= | =General Questions= | ||
==Can I try out Bugzilla somewhere?== | |||
If you want to take a test ride, there are test installations at http://landfill.bugzilla.org/, ready to play with directly from your browser. | |||
==What license is Bugzilla distributed under?== | ==What license is Bugzilla distributed under?== | ||
Bugzilla is covered by the Mozilla Public License. | Bugzilla is covered by the Mozilla Public License. | ||
Revision as of 23:07, 28 September 2006
General Questions
Can I try out Bugzilla somewhere?
If you want to take a test ride, there are test installations at http://landfill.bugzilla.org/, ready to play with directly from your browser.
What license is Bugzilla distributed under?
Bugzilla is covered by the Mozilla Public License. See details at http://www.mozilla.org/MPL/.
How do I get commercial support for Bugzilla?
http://www.bugzilla.org/support/consulting.html is a list of companies and individuals who have asked us to list them as consultants for Bugzilla.
There are several experienced Bugzilla hackers on the mailing list/newsgroup who are willing to make themselves available for generous compensation. Try sending a message to the mailing list asking for a volunteer.
What major companies or projects are currently using Bugzilla for bug-tracking?
There are dozens of major companies with public Bugzilla sites to track bugs in their products. We have a fairly complete list available on our website at http://bugzilla.org/installation-list/. If you have an installation of Bugzilla and would like to be added to the list, whether it's a public install or not, simply e-mail Gerv <gerv@mozilla.org>.
Who maintains Bugzilla?
A core team, led by Dave Miller (justdave@bugzilla.org).
How does Bugzilla stack up against other bug-tracking databases?
We can't find any head-to-head comparisons of Bugzilla against other defect-tracking software. If you know of one, please get in touch. In the experience of Matthew Barnson (the original author of this FAQ), though, Bugzilla offers superior performance on commodity hardware, better price (free!), more developer-friendly features (such as stored queries, email integration, and platform independence), improved scalability, greater flexibility, and superior ease-of-use when compared to commercial bug-tracking software.
If you happen to be a vendor for commercial bug-tracking software, and would like to submit a list of advantages your product has over Bugzilla, simply send it to <documentation@bugzilla.org> and we'd be happy to include the comparison in our documentation.
Why doesn't Bugzilla offer this or that feature or compatibility with this other tracking software?
It may be that the support has not been built yet, or that you have not yet found it. While Bugzilla makes strides in usability, customizability, scalability, and user interface with each release, that doesn't mean it can't still use improvement!
The best way to make an enhancement request is to file a bug at bugzilla.mozilla.org and set the Severity to 'enhancement'. Your 'request for enhancement' (RFE) will start out in the UNCONFIRMED state, and will stay there until someone with the ability to CONFIRM the bug reviews it. If that person feels it to be a good request that fits in with Bugzilla's overall direction, the status will be changed to NEW; if not, they will probably explain why and set the bug to RESOLVED/WONTFIX. If someone else has made the same (or almost the same) request before, your request will be marked RESOLVED/DUPLICATE, and a pointer to the previous RFE will be added.
Even if your RFE gets approved, that doesn't mean it's going to make it right into the next release; there are a limited number of developers, and a whole lot of RFEs... some of which are quite complex. If you're a code-hacking sort of person, you can help the project along by making a patch yourself that supports the functionality you require. If you have never contributed anything to Bugzilla before, please be sure to read the Developers' Guide and Contributors' Guide before going ahead.
Why MySQL? I'm interested in seeing Bugzilla run on PostgreSQL/Sybase/Oracle/Msql/MSSQL
MySQL was originally chosen because it is free, easy to install, and was available for the hardware Netscape intended to run it on.
Bugzilla 2.20 contains experimental support for PostgreSQL.
Bugzilla 2.22 contains complete, stable support for PostgreSQL. As of this release, using PostgreSQL with Bugzilla should be as stable as using MySQL. If you experience any problems with PostgreSQL compatibility, they will be taken as seriously as if you were running MySQL.
Red Hat once ran a version of Bugzilla that worked on Oracle, but that was long, long ago; that version (Bugzilla 2.8) is now obsolete, insecure, and totally unsupported. In August of 2005, Wim Coekaerts (Director of Linux Engineering at Oracle Corporation) wrote to Dave Miller confirming that Oracle intends to implement and support Bugzilla. Since then, no further information has been forthcoming. Track progress at Bug 189947.
Sybase support is no longer being worked on. Even if it eventually happens, it's VERY unlikely to work without the end-user-company having to stick a few developers on making several manual changes. Sybase is just NOT very standards-compliant (despite all the hype), and it turned out that way too much had to be changed to make it work -- like moving half of the application logic into stored procedures to get any kind of decent performance out of it. Bug 173130 is the relevant bug.
Bug 237862 is a good bug to read through if you'd like to see what progress is being made on general database compatibility.
What is /usr/bonsaitools/bin/perl?
Bugzilla used to have the path to perl on the shebang line set to /usr/bonsaitools/bin/perl because when Terry first started writing the code for mozilla.org he needed a version of Perl and other tools that were completely under his control. This location was abandoned for the 2.18 release in favor of the more sensible /usr/bin/perl. If you installed an older version of Bugzilla and created the symlink we suggested, you can remove it now (provided that you don't have anything else, such as Bonsai, using it and you don't intend to reinstall an older version of Bugzilla).
My perl is located at /usr/local/bin/perl and not /usr/bin/perl. Is there an easy to change that in all the files that have this hard-coded?
The easiest way to get around this is to create a link from one to the other: ln -s /usr/local/bin/perl /usr/bin/perl. If that's not an option for you, the following bit of perl magic will change all the shebang lines (that is to say, the line at the top of each file that starts with '#!' and contains the path) to something else:
perl -pi -e 's@#\!/usr/bin/perl@#\!/usr/local/bin/perl@' *cgi *pl
Sadly, this command-line won't work on Windows unless you also have Cygwin. However, MySQL comes with a binary called replace which can do the job:
C:\mysql\bin\replace "#!/usr/bin/perl" "#!C:\perl\bin\perl" -- *.cgi *.pl
If your perl path is something else again, just follow the above examples and replace /usr/local/bin/perl with your own perl path.
Once you've modified all your files, you'll also need to modify the t/002goodperl.t test, as it tests that all shebang lines are equal to /usr/bin/perl. (For more information on the test suite, please check out the appropriate section in the Developers' Guide.) Having done this, run the test itself:
perl runtests.pl 2 --verbose
to ensure that you've modified all the relevant files.
If using Apache on Windows, you can avoid the whole problem by setting the ScriptInterpreterSource directive to 'Registry'. (If using Apache 2 or higher, set it to 'Registry-Strict'.) ScriptInterperterSource requires a registry entry "HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command" to associate .cgi files with your perl executable. If one does not already exist, create it with a default value of "<full path to perl> -T", e.g. "C:\Perl\bin\perl.exe -T".
Is there an easy way to change the Bugzilla cookie name?
At present, no.
Does bugzilla run under mod_perl?
At present, no. Work is slowly taking place to remove global variables, use $cgi, and use DBI. These are all necessary for mod_perl (as well as being good for other reasons). Visit bug 87406 to view the discussion and progress.
How can Bugzilla be made to work under SELinux?
Unfortunately there are no step-by-step instructions, but the following URL contains hints on how to do it: http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizing.html