зеркало из https://github.com/mozilla/gecko-dev.git
144 строки
5.2 KiB
Plaintext
144 строки
5.2 KiB
Plaintext
This is Bugzilla. See <http://www.mozilla.org/bugs/>.
|
|
|
|
|
|
==========
|
|
DISCLAIMER
|
|
==========
|
|
|
|
This is not very well packaged code. It's not packaged at all. Don't
|
|
come here expecting something you plop in a directory, twiddle a few
|
|
things, and you're off and using it. Work has to be done to get
|
|
there. We'd like to get there, but it wasn't clear when that would
|
|
be, and so we decided to let people see it first.
|
|
|
|
|
|
|
|
============
|
|
INSTALLATION
|
|
============
|
|
|
|
(This section stolen heavily from the Bonsai INSTALL document. It's
|
|
also probably incomplete. "We're accepting patches", especially to
|
|
this document!)
|
|
|
|
First, you need some other things:
|
|
|
|
1) MySQL database server.
|
|
2) Perl5.004 or greater, including MySQL support, and modules
|
|
Date::Format and Chart::Base available from your nearest
|
|
CPAN server. See http://www.perl.com/CPAN.
|
|
ftp://ftp.cpan.org/pub/CPAN/authors/id/GBARR/TimeDate-1.08.tar.gz
|
|
ftp://ftp.cpan.org/pub/CPAN/authors/id/DBONNER/Chart-0.99.tar.gz
|
|
ftp://ftp.cpan.org/pub/CPAN/authors/id/LDS/GD-1.18.tar.gz
|
|
3) Some kind of HTTP server so you could use CGI scripts
|
|
|
|
Earlier versions of Bugzilla required TCL. THIS IS NO LONGER TRUE.
|
|
All dependencies on TCL have been removed.
|
|
|
|
1.1 Getting and setting up MySQL database
|
|
|
|
Visit MySQL homepage at http://www.tcx.se and grab the latest
|
|
stable binary release of the server. Sure, you can get sources and
|
|
compile them yourself, but binaries are the easiest and the fastest
|
|
way to get it up and running. Follow instructions found in
|
|
manual. There is a section about installing binary-only
|
|
distributions.
|
|
|
|
You should create database "bugs". It may be a good idea to make it
|
|
writable by all users on your machine and change access level
|
|
later. This would save you a lot of time trying to guess whether it's
|
|
permissions or a mistake in the script that make things fail.
|
|
|
|
|
|
1.2 HTTP server
|
|
|
|
You have a freedom of choice here - Apache, Netscape or any other
|
|
server on UNIX would do. The only thing - to make configuration easier
|
|
you'd better run HTTP daemon on the same machine that you run MySQL
|
|
server on. Make sure that you can access 'bugs' database with user
|
|
id you're running the daemon with.
|
|
|
|
globals.pl: $::db = Mysql->Connect("localhost", "bugs", "nobody", "")
|
|
|
|
In globals.pl, the database connect call uses a mysql account
|
|
name "bugs" (third argument to Mysql->Connect) to access the
|
|
bugs database. You may have to hack the code to use "nobody"
|
|
or whatever your HTTP server is running as.
|
|
|
|
|
|
2. Tweaking the Tools
|
|
|
|
All scripts look in /usr/bonsaitools/bin for perl. Make
|
|
the appropriate links or modify the paths in each script.
|
|
|
|
Make sure the directory containing the binaries is writable by the
|
|
web server. Bugzilla keeps some temporary files here.
|
|
|
|
Create an empty file in that directory named "comments"; make sure
|
|
it is writable by the web server. Also, create empty files named
|
|
"nomail" and "mail".
|
|
|
|
3. Setting up database
|
|
|
|
First, run mysql, and tell it "create database bugs;".
|
|
|
|
Now, you should be run all six scripts named make*.sh. This creates the
|
|
database tables and populates them a teeny bit.
|
|
|
|
|
|
4. Setting the parameters
|
|
|
|
At this point, you ought to be able to go and browse some pages. But you'd
|
|
like to customize some things.
|
|
|
|
Create yourself an account. (Try to enter a new bug, and it will
|
|
prompt you for your login. Give it your email address, and have it
|
|
mail you your password.) Go visit the query page; that ought to force
|
|
the creation of the "data/params" file in your installation dir. Edit the
|
|
data/params file, and change the line that sets "$::param{'maintainer'}" to
|
|
have your email address as the maintainer. Go visit the query page
|
|
again; there should now be a link at the bottom that invites you to
|
|
edit the parameters. (If you have cookies turned off, you'll have to
|
|
go to editparams.cgi manually.)
|
|
|
|
Tweak the parameters to taste. Be careful.
|
|
|
|
|
|
5. Set up the whining cron job.
|
|
|
|
It's a good idea to set up a daily cronjob that does
|
|
|
|
cd <your-installation-dir> ; ./whineatnews.pl
|
|
|
|
This causes email that gets sent to anyone who has a NEW bug that
|
|
hasn't been touched for several days. For more info, see the
|
|
whinedays and whinemail parameters.
|
|
|
|
|
|
6. Modifying your running system
|
|
|
|
Bugzilla optimizes database lookups by storing all relatively static
|
|
information in the versioncache file, located in the data/
|
|
subdirectory under your installation directory (we said before it
|
|
needs to be writable, right?!)
|
|
|
|
If you make a change to the structural data in your database (the
|
|
versions table for example), or to the "constants" encoded in
|
|
defparams.pl, you will need to remove the cached content from the data
|
|
directory (by doing a "rm data/versioncache"), or your changes won't
|
|
show up!
|
|
|
|
That file gets automatically regenerated whenever it's more than an
|
|
hour old, so Bugzilla will eventually notice your changes by itself,
|
|
but generally you want it to notice right away, so that you can test
|
|
things.
|
|
|
|
|
|
7. Optional: Bug Graphs
|
|
|
|
Place collectstats.pl in your crontab once/day to take a snapshot
|
|
of the number of open, assigned and reopened bugs for every
|
|
product. The tool will create a data/mining directory and append
|
|
the count to a file named for the product. After at least two points
|
|
of data are available, you can view a graph from the Bug Reports page.
|