This is Bugzilla. See . ========== 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 ; ./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.