gecko-dev/webtools/bugzilla

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 the Date::Format
      package from CPAN.
      ftp://ftp.cpan.org/pub/CPAN/authors/id/GBARR/TimeDate-1.08.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.