diff options
Diffstat (limited to 'docs/FAQ.html')
| -rw-r--r-- | docs/FAQ.html | 1557 |
1 files changed, 0 insertions, 1557 deletions
diff --git a/docs/FAQ.html b/docs/FAQ.html deleted file mode 100644 index f3c05cb6f..000000000 --- a/docs/FAQ.html +++ /dev/null @@ -1,1557 +0,0 @@ -<html> -<head> - <title>The Bugzilla FAQ v 0.2.4</title> -</head> -<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"> - -<center> -<h1> -The Bugzilla FAQ v 0.2.4</h1></center> -The contents of this file are subject to the Mozilla Public License Version -1.1 (the "License"); you may not use this file except in compliance with -the License. You may obtain a copy of the License at <a href="http://www.mozilla.org/MPL/">http://www.mozilla.org/MPL/</a> -. Software distributed under the License is distributed on an "AS -IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See -the License for the specific language governing rights and limitations -under the License. -<p>The Original Code is "The Bugzilla FAQ". -<p>The Initial Developer of the Original Code is AtHome Corporation. Portions -created by AtHome are Copyright © 1995-2000 AtHome Corporation. All -Rights Reserved. @Home, Excite@Home, @Work, and Excite are the trademarks -of At Home Corporation, and may be registered in certain jurisdictions -<p>Contributor(s): -<ul> -<li> -<a href="mailto:mbarnson@excitehome.net">Matthew P. Barnson</a></li> - -<li> -<a href="mailto:terry@mozilla.org">Terry Weissman</a></li> - -<li> -<a href="mailto:tara@tequilarista.org">Tara Hernandez</a></li> - -<li> -Various contributors (you know who you are... thank you!)</li> -</ul> -Last change: June 7, 2000 -<p>Changes: -<br>Version 0.2: Initial public release. (April 10, 2000) -<br>Version 0.2.1: Fixed formatting, released as HTML. Also corrected -incorrect fix for missing bugs from queries (it's syncshadowdb, not processmail) -and information about bugzilla maintainers (April 10,2000) -<br>Version 0.2.2: (May 15, 2000) -<ol> -<li> -Fixed mailto: links (they were showing up as "documents/"... weird)</li> - -<li> -Added new sections:</li> - -<ol> -<li> -API notes (such as it is)</li> - -<li> -common feature requests</li> - -<li> -more FAQ's</li> - -<li> -Fixed several tpyos</li> -</ol> - -<li> -Take into account recent submissions to the newsgroup</li> - -<li> -Removed "Bugzilla Gotchas" section and integrated entries into "Bugzilla -Bugs"</li> -</ol> - -<p><br>Version 0.2.4: (June 7, 2000) -<ol> -<li> -Added Dave Lawrence's excellent RedHat Bugzilla differences section verbatim.</li> - -<li> -Added more information on Loki Bugzilla ("Fenris").</li> - -<li> -Added questions from some corporate customers</li> - -<li> -Removed unused text in API section</li> - -<li> -Added information about other documentation (pending)</li> - -<li> -Added a section for pointy-haired-bosses</li> - -<li> -This will be the last release in strictly HTML format. Source will be SGML shortly, with -HTML and TXT versions included with the package from this point on</li> -</ol> - -<p><br>Maintainer: <a href="mailto:mbarnson@excitehome.net">Matthew P. -Barnson</a> -<br> -<center> -<h2> -Table of Contents</h2></center> - -<center><a href="#INTRODUCTION">INTRODUCTION</a> -<br><a href="#BZGENERAL">BUGZILLA GENERAL</a> -<br><a href="#RHBZ">--redhat bugzilla</a> -<br><a href="#LOKIBZ">--loki bugzilla</a> -<br><a href="#PHB">--phb bugzilla</a> -<br><a href="#BZINSTALLATION">BUGZILLA INSTALLATION</a> -<br><a href="#BZCONFIGURATION">BUGZILLA CONFIGURATION</a> -<br><a href="#BZSECURITY">--security</a> -<br><a href="#BZEMAIL">--email</a> -<br><a href="#BZDATABASE">--database</a> -<br><a href="#BZNT">BUGZILLA and WINDOWS NT</a> -<br><a href="#BZUSE">BUGZILLA USE</a> -<br><a href="#BZKNOWNBUGS">BUGZILLA KNOWN BUGS</a> -<br><a href="#BZHACKING">BUGZILLA HACKING</a> -<br><a href="#BZAPI">--API</a></center> - -<p> -<hr WIDTH="100%"> -<center> -<h2> -<a NAME="INTRODUCTION"></a>INTRODUCTION</h2></center> - -<center>or "And all this time we thought we were *reducing* the number -of bugs"</center> - -<hr WIDTH="100%"> -<br>The Bugzilla FAQ has a new home! In addition to availability -via CVS and released versions 2.12 and higher of Bugzilla, you can find -the latest & greatest version of the FAQ at <a href="http://www.trilobyte.net/barnsons/">http://www.trilobyte.net/barnsons/</a>. -This is a living document; please be sure you are up-to-date with the latest -version before mirroring. -<p>The Bugzilla FAQ is designed to answer common user questions outside -the scope of the README file and supporting documentation in an easy "question -and answer" format. Where appropriate, this FAQ will refer to URLs rather -than including documents in their entirety to ensure completeness even -should this FAQ become out of date. -<p>This FAQ is not maintained by Netscape or Netscape employees, so please -do not contact them regarding errors or omissions contained herein. Please -direct all questions, comments, updates, flames, etc. to <a href="mailto:mbarnson@excitehome.net">Matthew -P. Barnson </a>(barnboy or barnhome on irc.mozilla.org in #mozwebtools). -<p>I'm sure I've made some glaring errors or omissions in this paper -- -please <a href="mailto:mbarnson@excitehome.net">email me</a> corrections -or post corrections to the netscape.public.mozilla.webtools newsgroup. -<p>Bugzilla attracts very intelligent, competent people who need a good -bug-tracking system to support their projects, so I make a few assumptions -in this FAQ: -<ol> -<li> -You are using UNIX, or you use NT and have a high tolerance for pain.</li> - -<li> -You are a competent systems administrator with a working knowledge of UNIX -shells, security, Apache or Netscape/iPlanet web server, Perl, and MySQL.</li> - -<li> -You are not easily frustrated, and have a strong ability to figure out -answers to problems.</li> -</ol> - -<hr WIDTH="100%"> -<center> -<h2> -<a NAME="BZGENERAL"></a>BUGZILLA GENERAL</h2></center> - -<center>or "It's not a bug. It's a feature."</center> - -<hr WIDTH="100%"> -<p><b><i>Q:</i></b> <i>Where can I find information about bugzilla?</i> -<br><b><i>A:</i></b> You can stay up-to-date with the latest bugzilla information -at <a href="http://www.mozilla.org/projects/bugzilla/">http://www.mozilla.org/projects/bugzilla/</a>. -<p><b><i>Q:</i></b> <i>What license is Bugzilla distributed under?</i> -<br><b><i>A:</i></b> Bugzilla is under the Mozilla Public License. See -details at <a href="http://www.mozilla.org/MPL/">http://www.mozilla.org/MPL/</a> -<p><b><i>Q:</i></b> <i>How do I get commercial support for Bugzilla?</i> -<br><b><i>A:</i></b> As far as I know, there are not yet any companies -that offer commercial Bugzilla support. However, I've heard there are consulting -companies that will install and maintain a Bugzilla installation for charge, -and would accept responsibility for its upkeep. I'm not sure which large -consulting firms do this yet -- I'm open to more contributions in this -area. -<p><b><i>Q:</i></b> <i>What major companies or projects are currently using -Bugzilla for bug-tracking?</i> -<br><b><i>A:</i></b> This is by no means a complete list, and is assembled -from contributions and about 10 minutes of searching on AltaVista. Contributions -welcome: -<ul> -<li> -<a href="http://www.netscape.com/">Netscape/AOL</a></li> - -<li> -<a href="http://www.mozilla.org/">Mozilla.org</a></li> - -<li> -<a href="http://www.excitestores.com/">AtHome Corporation</a></li> - -<li> -<a href="http://www.redhat.com/">Red Hat</a></li> - -<li> -<a href="http://fenris.lokigames.com/">Loki Entertainment Software</a></li> - -<li> -<a href="http://www.suse.com/">SuSe Corp</a></li> - -<li> -<a href="http://www.horde.org/">The Horde Project</a></li> - -<li> -<a href="http://www.eazel.com/">The Eazel Project</a></li> -</ul> -<b><i>Q:</i></b> <i>Who maintains Bugzilla?</i> -<br><b><i>A:</i></b> <a href="mailto:tara@tequilarista.org">Tara Hernandez</a> -is the current maintainer of Bugzilla. It was originally written and maintained -by <a href="mailto:terry@mozilla.org">Terry Weissman</a>, but he is no -longer heavily involved (Tara adds, "These days, <a href="mailto:terry@mozilla.org">Terry</a> -just hangs around and heckles"). The Quality Assurance contact for -Bugzilla, who makes sure we don't get too far out of line is <a href="mailto:matty@box.net.au">Matthew -Tuck</a>. You'll often hear from and about <a href="mailto:dmose@mozilla.org">Dan -Mosedale </a>and <a href="mailto:endico@mozilla.org">Dawn Endico</a>. Check -out their bios and responsibilities at <a href="http://www.mozilla.org/about.html">http://www.mozilla.org/about.html.</a> -They bear primary responsibility for keeping the current bugzilla.mozilla.org -site up-to-date, and have a vital interest in ensuring Bugzilla moves forward -(and doesn't break!) -<p><b><i>Q:</i></b> <i>Why does Bugzilla use .png files instead of .gifs -for graphs?</i> -<br><b><i>A:</i></b> Patent restrictions (see <a href="http://www.gnu.org/philosophy/gif.html">http://www.gnu.org/philosophy/gif.html</a> -for details). If you're using a recent version of the GD library and a -recent version of Bugzilla, this is no longer a FAQ. -<p><b><i>Q:</i></b> <i>How does Bugzilla stack up against other bug-tracking -databases?</i> -<br><b><i>A:</i></b> As far as I know, there have been no feature-by-feature -comparisons to other bug-tracking systems. However, here are some -primary reasons people cite for moving to Bugzilla: -<ol> -<li> -Customizability</li> - -<li> -Maintainability (quick security fixes and trivial upgrades)</li> - -<li> -Industry support (<a href="http://www.mysql.com/">MySQL</a>, <a href="http://www.oracle.com/">Oracle</a>, -instead of custom little <a href="http://www.sqlcourse.com/">SQL</a> DB)</li> - -<li> -Adherence to web standards (<a href="http://web.golux.com/coar/cgi/">CGI</a>, -<a href="http://www.perl.org/">Perl</a>, -SQL)</li> - -<li> -Speed, proven on very large installations (<a href="http://bugzilla.mozilla.org/">bugzilla.mozilla.org</a>)</li> - -<li> -<a href="http://www.usenix.org/">UNIX</a>-based</li> - -<li> -<a href="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.html">Open -Source</a>.</li> - -<li> -Price. However, don't let price be the selling point of Bugzilla --- it survives on its own merits.</li> -</ol> -<b><i>Q:</i></b> <i>How do I change my username in Bugzilla?</i> -<br><b><i>A:</i></b> If you are the administrator, open up editusers.cgi -and change the login name. Simple! -<p><i><b>Q:</b> Why doesn't Bugzilla offer this or that feature or compatability -with <insert cool tracking software here>?</i> -<br><b><i>A:</i></b> Terry writes, -<blockquote>I wrote Bugzilla primarily for mozilla.org's use. It is a secondary -concern (but one still important to me) that it be of use to other folks, -too. So, rather than spend a lot of time making everything thoroughly portable -and easy to install, I just threw it over the wall, and prayed that random -developers would help pitch in and make things easier for everyone.(I'm -being a little hard on myself here. I *did* spend a week porting the whole -thing from TCL to Perl, just so that outside folk would have a chance of -using it. You shoulda seen it before...)</blockquote> -<b><font color="#FF0000">UPDATE</font></b>: Bugzilla is making tremendous -strides in usability, customizability, scalability, and user interfaces. -It is widely considered the most complete and popular open-source bug database -in existence. <a href="http://www.mozilla.org/bugs/source.html">Download -a copy today!</a> -<p><b><i>Q:</i></b> <i>Why MySQL? I'm interested in seeing this run on -(insert "real" RDBMS name here)...</i> -<br><b><i>A:</i></b> Terry answers, -<blockquote>You're not the only one. But *I* am not very interested. I'm -not real SQL or database person. I just wanted to make a useful tool, and -build it on top of free software. So, I picked MySQL, and learned SQL by -staring at the MySQL manual and some code lying around here, and -<br>wrote Bugzilla. I didn't know that Enum's were non-standard SQL. I'm -not sure if I would have cared, but I didn't even know. So, to me, things -are "portable" because it uses MySQL, and MySQL is portable enough. I fully -understand (now) that people want to be portable to other databases, but -that's never been a real concern of mine.</blockquote> -<b><font color="#FF0000">UPDATE</font></b>: Looks like RedHat might land -changes real soon that will bring some more portability to Bugzilla. -However, they are in severe need of help. Please contact <a href="mailto:dkl@redhat.com">Dave -Lawrence</a> if you are interested in helping this effort. -<p><b><i>Q:</i></b> <i>Why do the scripts say "/usr/bonsaitools/bin/perl" -instead of "/usr/bin/perl" or something else?</i> -<br><b><i>A:</i></b> Mozilla.org uses /usr/bonsaitools/bin/perl. The prime -rule in making submissions is "don't break bugzilla.mozilla.org". If it -breaks it, your patch will be reverted faster than you can do a diff. -Terry says: -<blockquote>Purely my own convention. I wanted a place to put a version -of Perl and other tools that was strictly under my control for the various -webtools, and not subject to anyone else. Edit it to point to whatever -you like.</blockquote> - -<blockquote> -<h3> -<a NAME="RHBZ"></a>Red Hat Bugzilla</h3> -</blockquote> - -<p><br><b><i>Q:</i></b> <i>What about Red Hat Bugzilla?</i> -<br><b><i>A:</i></b> <a href="http://www.redhat.com/">Red Hat</a> has a -(arguably more user-friendly/customizable/scalable buzzword here) version -of Bugzilla available. Check it out at <a href="http://bugzilla.redhat.com/">http://bugzilla.redhat.com -</a>and -the sources at <a href="ftp://people.redhat.com/dkl/">ftp://people.redhat.com/dkl/</a>. -They've set theirs up to work with Oracle out of the box. The buzz says -their changes will be landing in the source tree "real soon now". -Note that it is based primarily upon the 2.8 Bugzilla tree; Bugzilla has -made some tremendous advances since the 2.8 release. I recommend -you download the primary Bugzilla as well as Red Hat's to check out the -differences for yourself. Red Hat Bugzilla's maintainer, <a href="mailto:dkl@redhat.com">Dave -Lawrence</a>, when asked about landing the changes from the Red Hat fork, -notes, -<blockquote>Somebody needs to take the ball and run with it. I'm -the only maintainer and am very pressed for time.</blockquote> -<i><b>Q:</b> What are the primary benefits of Red Hat Bugzilla? (answer -by Dave Lawrence, of Red Hat)</i> -<br><i>A: </i>For the record, we are not using any template -type implementation for the cosmetic changes maded to Bugzilla. It -is just alot of html changes in the code itself. I admit I may have -gotten a little carried away with it but the corporate types asked -for a more standardized interface to match up with other projects -relating to Red Hat web sites. A lot of other web based internal tools -I am working on also look like Bugzilla. -<br> I do want to land the changes that I have made to Bugzilla -but I may have to back out a good deal and make a different version -of Red Hat's Bugzilla for checking in to CVS. Especially the cosmetic -changes because it seems they may not fit the general public. -I will do that as soon as I can. I also still do my regular QA responsibilities -along with Bugzilla so time is difficult sometimes to come by. -<br> There are also a good deal of other changes that were requested -by management for things like support contracts and different permission -groups for making bugs private. Here is a short list of the major -changes that have been made: -<ol> -<li> -No enum types. All old enum types are now separate smaller tables.</li> - -<li> -No bit wise operations. Not all databases support this so they were changed -to a more generic way of doing this task.</li> - -<li> -Bug reports can only be altered by the reporter, assignee, or a privileged -bugzilla user. The rest of the world can see the bug but in a non-changeable -format (unless the bug has been marked private). They can however -add comments, add and remove themselves from the CC list.</li> - -<li> -Different group scheme. Each group has an id number related to it. -There is a user_group table which contains userid to groupid mappings to -determine which groups each user belongs to. Additionally there is -a bug_group table that has bugid to groupid mappings to show which groups -can see a particular bug. If there are no entries for a bug in this table -then the bug is public.</li> - -<li> -Product groups. product_table created to only allow certain products to -be visible for certain groups in both bug entry and query. This was particulary -helpful for support contracts.</li> - -<li> -Of course many (too many) changes to Bugzilla code itself to allow use -with Oracle and still allow operation with Mysql if so desired. Currently -if you use Mysql it is set to use Mysql's old permission scheme to keep -breakage to a minimum. Hopefully one day this will standardize on one style -which may of course be something completely different.</li> - -<li> -Uses Text::Template perl module for rendering of the dynamic HTML pages -such as enter_bug.cgi, query.cgi, bug_form.pl, and for the header and footer -parts of the page. This allows the html to be separate from the perl code -for customizing the look and feel of the page to one's preference.</li> - -<li> -There are many other smaller changes. There is also a port to Oracle -that I have been working on as time permits but is not completely</li> - -<li> -finished but somewhat usable. I will merge it into our standard code -base when it becomes production quality. Unfortunately there will -have to be some conditionals in the code to make it work with other -than Oracle due to some differences between Oracle and Mysql. </li> -</ol> - Both the Mysql and Oracle versions of our current code base -are available from ftp://people.redhat.com/dkl. If Terry/Tara wants -I can submit patch files for all of the changes I have made and he -can determine what is suitable for addition to the main bugzilla cade -base. But for me to commit changes to the actual CVS I will need to -back out alot of things that are not suitable for the rest of the -Bugzilla community. I am open to suggestions. -<br> -<p>Q: What's the current status of Red Hat Bugzilla? -<br><font color="#FF0000">Update</font>: From Dave Lawrence (June 7 2000) -<blockquote>I suppose the current thread warrants an update on the status -of Oracle and bugzilla ;) We have now been running Bugzilla 2.8 on Oracle -for the last two days in our production environment. I tried to do as much -testing as possible with it before going live which is some of the reason -for the long delay. I did not get enough feedback as I would have liked -from internal developers to help weed out any bugs still left so I said -"Fine, i will take it live and then I will get the feedback I want :)" -So it is now starting to stabilize and it running quite well after working -feverishly the last two days fixing problems as soon as they came in from -the outside world. The current branch in cvs is up2date if anyone would -like to grab it and try it out. The oracle _setup.pl is broken right now -due to some last minute changes but I will update that soon. Therefore -you would probably need to create the database tables the old fashioned -way using the supplied sql creation scripts located in the ./oracle directory. -We have heavy optimizations in the database it self thanks to the in-house -DBA here at Red Hat so it is running quite fast. The database itself -is located on a dual PII450 with 1GB ram and 14 high voltage differential -raided scsi drives. The tables and indexes are partitioned in 4 chuncks -across the raided drive which is nice because when ever you need to do -a full table scan, it is actually starting in 4 different locations on -4 different drives simultaneously. And the indexes of course are on separate -drives from the data so that speeds things up tremendously. When -I can find the time I will document all that we have done to get this -thing going to help others that may need it. -<p>As Matt has mentioned it is still using out-dated code and with a -little help I would like to bring everything up to date for eventual -incorporation with the main cvs tree. Due to other duties I have with the -company any help with this wiould be appreciated. What we are using -now is what I call a best first effort. It definitely can be improved on -and may even need complete rewrites in a lot of areas. A lot of changes -may have to be made in the way Bugzilla does things currently to -make this transition to a more generic database interface. Fortunately -when making the Oracle changes I made sure I didn't do anything that -I would consider Oracle specific and could not be easily done with other -databases. Alot of the sql statements need to be broken up into smaller -utilities that themselves would need to make decisions on what database -they are using but the majority of the code can be made database neutral. -<h3> -<a NAME="LOKIBZ"></a>Loki Bugzilla (AKA: Fenris)</h3> -</blockquote> -<b><i><font color="#FF0000">Note: </font></i></b>This is based primarily -on a single email conversation with the first developer of Fenris, <a href="mailto:briareos@lokigames.com">Michael -Vance</a>. Maintenance of Fenris has since been handed off to <a href="mailto:raistlin@lokigames.com">Raphael -Barrerro</a> <raistlin@lokigames.com>. -<p><i><b>Q: </b>What about Loki Bugzilla?</i> -<br><b><i>A:</i></b> Loki Games has a customized version of Bugzilla -available at <a href="http://fenris.lokigames.com/">http://fenris.lokigames.com</a>. -From that page, -<blockquote>You may have noticed that Fenris is a fork from Bugzilla-- -our patches weren't suitable for integration --and a few people have expressed -interest in the code. Fenris has one major improvement over Bugzilla, -and that is individual comments are not appended onto a string blob, they -are stored as a record in a separate table. This allows you to, for instance, -separate comments out according to privilege levels in case your bug database -could contain sensitive information not for public eyes. We also provide -things like email hiding to protect user's privacy, additional fields such -as 'user_affected' in case someone enters someone else's bug, comment editing -and deletion, and more conditional system variables than Bugzilla does -(turn off attachments, qacontact, etc.).</blockquote> -<i><b>Q:</b> Are you interested in landing your [Fenris] changes -back in the main tree so Fenris can live on the tip again?</i> -<br><b><i>A:</i></b> Sure, although many of them are probably obsolete -by now. -<p><b><i>Q:</i></b> <i>If so, when?</i> -<br><b><i>A:</i></b> Well, if there's anything interesting, people -of course can just grab the code. I don't really maintain it anymore. We -have a real, honest to goodness sysadmin, Raphael Barrerro, who works on -it now. His email is raistlin@lokigames.com. -<p><i><b>Q:</b> Main tree bugzilla changed for 2.10 to storing individual -comments in a separate table. Are there reasons for users to use -Fenris, based on Bugzilla 2.8, over main tree 2.10 or the current CVS version? -What are they?</i> -<br><b><i>A: </i></b> I have no idea :). IMNSHO, Bugzilla is an interesting -piece of software in that it has a lot of logic encoded into it that is -sometimes really cumbersome to some people, and then it doesn't have *enough* -logic in it for other people's tastes. If I were going to start over, I -would again try to use the CVS and get any changes I felt necessary integrated. -But for us, right now, it works fine, so we haven't bothered to really -change our setup. -<p><b><i>Q:</i></b> <i>What do you mean by "our patches weren't suitable -for integration" on your web page?</i> -<br><b><i>A:</i></b> Basically, I did not know: -<ol> -<li> -Apache</li> - -<li> -MySQL, or</li> - -<li> -Perl</li> -</ol> -when I was charged with the task of getting our Bugzilla up and running. -Therefore I found it necessary to futz with a lot of things, -<br>mostly formatting of the Perl code, until I could understand what they -were doing. This resulted in lots of whitespace diff, and even when I created -a diff with -B (no whitespace), it still had too much crud in it. I also -hadn't written any migration scripts or anything. Terry didn't want to -bother with it, and that was cool with me. Terry and I had a really weird -conversation that I didn't quite understand, about us using CVS HEAD, etc., -but I just didn't have the time/energy for something that already worked. -<br> -<blockquote> -<h3> -<a NAME="PHB"></a>Pointy-Haired-Boss Questions</h3> -</blockquote> -<b><font color="#FF0000">Note</font></b>: The title of this section doesn't -mean you're a PHB -- it just means you probably HAVE a PHB who wants to -know this :) -<p><i><b>Q:</b> Is Bugzilla web-based or do you have to have specific -software or specific operating system on your machine?</i> -<br><b><i>A:</i></b> It is web and e-mail based. You can edit -bugs by sending specially formatted email to a properly configured Bugzilla, -or control via the web. Bugzilla works best with Netscape Navigator, but -works fine with IE (just some Javascript is disabled for IE). -<p><i><b>Q: </b> Has anyone you know of already done any Bugzilla -integration with Perforce (SCM software)?</i> -<br><b><i>A:</i></b> Not to my knowledge -- but that would be a question -much better asked in the newsgroup (news://netscape.public.mozilla.webtools). -<p><i><b>Q:</b> Does Bugzilla allow the user to track multiple projects?</i> -<br><b><i>A:</i></b> It's not specifically a "project management -tool", although it does have some project management features, such as -the ability for a task/bug to "block" another task/bug. We use it -here at Excite@Home to track requests to our Network Operations Center, -software defects in our online inventories, requests for enhancement, quality -assurance, personnel tasks, and other things. -<br> So the answer is: Yes, it handles multiple projects very well. -When discussing Bugzilla with people who use it a lot, it's helpful to -refer to a "project" as a "product", individual areas of the project as -"components", and tasks as "bugs". -<p><i><b>Q:</b> If I am on many projects, and search for all bugs -assigned to me, will Bugzilla list them for me and allow me to sort by -project, severity etc?</i> -<br><b><i>A: </i></b> The heart of the Bugzilla system is the query -interface. Within that query interface, you can customize extremely -powerful queries to deliver exactly what you need. Once delivered, -you can sort by age (bug ID number), severity, priority, platform, owner, -current state, or current result (only for "resolved" bugs). -<br> You cannot sort a query by product/project at this time -- most -people consider the current options sufficient. We are trying very -hard to reduce complexity in Bugzilla. I'm personally involved in -a half-dozen products in Bugzilla, and routinely just sort by priority. -<p><i><b>Q:</b> Does Bugzilla allow attachments (text, screenshots, -urls etc)? If yes, are there any that are NOT allowed?</i> -<br><b><i>A:</i></b> Yes, it allows any kind of attachment. -However, if you do not have a MIME type defined for that kind of file in -your web *server*, the browser may klonk on you. URL's in comments -are automatically hyperlinked if they are properly formatted (http://www.somedomain.com), -but any HTML in a comment shows up as raw html, not the formatting you'd -expect. If someone refers to "bug #4444" it's automatically hyperlinked -to that bug in the existing database. It's pretty cool. -<p><i><b>Q: </b> Does Bugzilla allow us to define our own priorities -and levels? Do we have complete freedom to change the labels of fields -and format of them, and the choice of acceptable values?</i> -<br><b><i>A: </i></b> In part. Priority, severity, target milestones, -product names, and many many other fields are completely configurable. -However, at this time for certain types of changes you need someone who -knows some Perl and HTML -- not a lot, but enough to provide consistency -and be able to re-apply your customizations if you update your installation -of Bugzilla. -<p><i><b>Q: </b> Does Bugzilla provide any reporting features, metrics, -graphs, etc? You know, the type of stuff that management likes to see. -:)</i> -<br><b><i>A:</i></b> Yes. Check out http://bugzilla.mozilla.org/reports.cgi -for some pre-cooked reports. The reports other than the pre-fab ones -that you can create are limited only by your imagination and experience -in Perl. -<p><i><b>Q: </b> Is there email notification and if so, what do you -see when you get an email? Do you see bug number and title or is it only -the number?</i> -<br><b><i>A: </i></b> You can choose to see complete status of the -bug (using old email tech) or just the changes (using new email tech). -The subject is just the bug ID and short description of the bug, but the -content is very complete. -<p><i><b>Q: </b> If there is email notification, can it be set up -to send to multiple people, some on the To List, CC List, BCC List etc?</i> -<br><b><i>A: </i></b> You bet! By default, the person who reported -the bug, the person to whom the bug is assigned, and anyone on the CC list -for the bug will get email notification when anything regarding the bug -changes. You can also enable a "Q/A Contact" field that will assign -a default Q/A person to monitor the bug and ensure it's completed correctly -(we use this a lot and love it). The -<br>equivalent to a "BCC" list is a "watcher": someone who watches another -person's bugs (if they are out of town, whatever). We have several -of these people who need to see what bugs someone else is working on (team -leads, coding partners, etc.) -<p><i><b>Q: </b> If there is email notification, do users have to -have any particular type of email application? For example, our users have -a variety of email apps in use, like Outlook, Netscape Mail, Eudora etc. -Our system would need to work with just about anything.</i> -<br><b><i>A:</i></b> The emails SENT from Bugzilla will work with -any mail reader that's reasonably current (newer than about 5 years old). -However, if you set up the email RECEPTION capabilities of Bugzilla, it's -important your users configure their mailreader to send mail as plain text -instead of HTML. HTML mail sent to Bugzilla looks horrible. -<p><i><b>Q: </b> If I just wanted to track certain bugs, as they go -through life, can I set it up to alert me via email whenever that bug changes, -whether it be owner, status or description etc.?</i> -<br><b><i>A:</i></b> Yes. You could, for instance, set yourself -up as the default QA contact for all bugs in a certain component of a product, -and would be CC'd on every single bug that came into that component. -<p><i><b>Q: </b> Does Bugzilla allow data to be imported and exported? -If I had outsiders write up a bug report using a MS Word bug template, -could that template be imported into "matching" fields? If I wanted to -take the results of a query and export that data to MS Excel, could I do -that?</i> -<br><b><i>A: </i></b> Rudimentary exporting ability is currently in -development, but is not ready for prime-time. Ditto for importing -data. However, it works against an industry-standard database (MySQL), -so anyone with a little SQL knowledge can create queries to import and -export any data they want. That's one of the reasons development -is going slow on import/export in Bugzilla: SQL already -<br>has it. It requires a certain level of familiarity with SQL though. -<p><i><b>Q: </b>Does Bugzilla allow fields to be added, changed or -deleted? If I want to customize the bug submission form to meet our needs, -can I do that using our terminology?</i> -<br><b><i>A: </i></b> This is really two questions in one. -<br> Bugzilla allows some fields to be added, changed, and deleted -with ease using the standard parameters. Realize, since you have -the code (and Bugzilla is really not terribly complicated), you can change -ANYTHING to behave however you want it. However, the more adjustments -you make to the code, the more painful your next upgrade will be as you -re-apply your custom -<br>patches. On the other hand, you can create your own HTML bug -submission form to make it look however you want. Check http://www.mozilla.org/quality/help/bug-form.html -for an example of what can be done creating a standard HTML bug submission -form. It makes some things much easier, and submitters never have -to have a clue what the actual names of your fields are -- just the people -who work with the bugs every day do. -<p><i><b>Q: </b> Has anyone converted Bugzilla to another language -to be used in other countries? Is it localizable?</i> -<br><b><i>A:</i></b> There are efforts underway to allow easy indo-european -localization of Bugzilla, but i18n (Kanji, Chinese, etc.) are a long way -off. So, to answer your question, right now, no. -<p><i><b>Q:</b> Can a user create and save reports? Can they do this in -Word format? Excel format?</i> -<br><b><i>A:</i></b> Yes, no, and no. -<p><i><b>Q:</b> Can a user re-run a report with a new project, same -query?</i> -<br><b><i>A:</i></b> Yes. -<p><i><b>Q:</b> Can a user modify an existing report and then save -it into another name?</i> -<br><b><i>A: </i></b> Umm... You'd save the report as HTML from -your browser. You can modify it however you want after that. -<p><i><b>Q:</b> Does Bugzilla have the ability to search by word, -phrase, compound search?</i> -<br><b><i>A:</i></b> You can search by just about ANYTHING. -If you know basic boolean formatting, you can go completely crazy and do -things without even using the query interface (create your own custom query -in the location bar in your browser). We routinely search here by -descriptions, subjects, dates, users, reporters, projects, severity, priority, -and anything else that strikes our fancy. -<p><i><b>Q: </b> Can the admin person establish separate group and -individual user privileges?</i> -<br><b><i>A: </i></b> Yes, using Bug Group Sentry. Right now, -it's not terribly granular, though: you can restrict users to editing bugs -assigned to them, reported by them, assigned to a particular product, etc. -but cannot restrict them based on product components, allow access to only -certain bugs outside their product, etc. -<p><i><b>Q: </b> Does Bugzilla provide record locking when there is -simultaneous access to the same bug? Does the second person get a notice -that the bug is in use or how are they notified?</i> -<br><b><i>A: </i></b> If someone has a bug open and another person -attempts to write to the bug, you get a "mid-air collision" error in Bugzilla. -the second person is told who currently has the existing record locked, -and is told he/she cannot commit the bug until they have finished editing -it. You can specify a timeout value (ours is 30 minutes) where it -will break locks on the database, -<br>assuming someone just left the edit screen up. -<p><i><b>Q: </b>Are there any backup features provided?</i> -<br><b><i>A:</i></b> You have the ability to lock all users out of -the database for backups via the Bugzilla interface or using MySQL itself. -Once you've locked people out of the database, use some backup utility -standard to your operating system. -<p><i><b>Q: </b> Can users be on the system while a backup is in progress?</i> -<br><b><i>A: </i></b> If they make a change, you can end up with a -corrupt database on your backup tape. Bugzilla databases are relatively -small. We have over 5000 bugs in our database and a backup takes -about 45 seconds. We lock the MySQL database, copy the databases -over to a second hard drive, unlock the database, and that second hard -drive is covered by our standard backup procedures. -<br> You may wish to consider a robust backup solution, like ARCserveIT, -which will backup up open files by finding a time when it can lock the -file, copy it to memory, unlock it, and back it up. That product -is the "Open Files Agent", or OFA. That would allow you to never -have to down your database just to back it up -- but it's a good idea to -plan on a daily maintenance period in which it's backed up, for the time -when your database grows absolutely huge. -<p><i><b>Q: </b> What type of human resources are needed to be on -staff to install and maintain Bugzilla? Specifically, what type of skills -does the person need to have? I need to find out if we were to go with -Bugzilla, what types of individuals would we need to hire and how much -would that cost vs buying an "Out-of-the-Box" solution.</i> -<br><b><i>A:</i></b> My experience with "Out-of-the-Box" solutions -are these: -<ol> -<li> -They are very proprietary. Good luck getting data out of them into -something else unless you pay the company to create an export filter for -you.</li> - -<li> -They generally have exhorbitant licensing fees.</li> - -<li> -They tend to lock you in to a particular hardware or software platform</li> - -<li> -They frequently cater much more to the management aspect of bug reporting -than using it as a day-to-day bug-tracking system. In other words, -managers/marketdroids love it, your programmers hate it.</li> - -<li> -Forget interoperability with other programs.</li> - -<li> -Many use sub-standard database management techniques. The commercial -solution I have in mind claims to have an "SQL database" when in fact they -wrote a small, crippled SQL query method to talk to a heirarchy of flat -text files.</li> - -<li> -"Out-of-the-box" solutions just seem to suck most of the time. That's -just my opinion, though ;)</li> -</ol> - I'd recommend you hire a consultant to get Bugzilla working the -way you want, then it's "fire-and-forget". It takes virtually no -maintenance once it's up and running, if you don't wish to remain "on the -tip" of the latest development changes. However, finding a consultant -who already knows Bugzilla may be challenging, I think. -<br> If you want to hire someone to run it, I'd recommend someone -with strong UNIX systems administration skills and light Perl and HTML -skills. They don't need much Perl or HTML knowledge coming in -- -Bugzilla is a pretty standard type of program to install, so a decent SysAdmin -can get it done easily. If you're using NT, you probably require -an NT admin with UNIX experience, very strong Perl skills, and light HTML -skills. Personally, I wouldn't hire someone JUST to maintain Bugzilla. -If you already have a network admin on staff, get him working on it. -A basic install requires 1-8 hours of work (depending on how familiar you -are with -<br>it). Setting up cool email gateways and tweaking configuration -parameters seems to suck up enormous amounts of time. -<p><i><b>Q: </b> What time frame are we looking at if we decide to -hire people to install and maintain the Bugzilla? Is this something that -takes hours or weeks to install and a couple of hours per week to maintain -and customize or is this a multi-week install process, plus a full time -job for 1 person, 2 people, etc?</i> -<br><b><i>A:</i></b> It's really hard to say -- it depends on the -level of commitment you want. If you want someone on-staff who's an absolute -expert on the system, plan on them working on it full-time for a week, -then 10 hours a week for a few months thereafter. If you just want -the thing to work and don't want to worry about how it works, just hire -that consultant for a week and call it -<br>good. -<br> Personally, I spend about 15 minutes a week maintaining our -installation Bugzilla. But since I'm the documentation person for -Bugzilla, I spend about 10 hours a week documenting, answering questions -like this, etc. -<br> If you get somebody to install Bugzilla, and they don't have -at least a basic installation mostly functional within a day on UNIX, or -within a week on NT, you probably should consider getting a different admin -to install it. -<p><i><b>Q:</b> Is there any licensing fee or other fees for using -Bugzilla? Any out-of-pocket cost other than the bodies needed as identified -above?</i> -<br><b><i>A:</i></b> No, Bugzilla is free software (free as in speech -and free as in beer) licensed under the <a href="http://www.mozilla.org/MPL/">Mozilla -Public License</a>. However, depending on your level of expertise you may -wish to find a company that you can pay to maintain it for you if you really -need somebody to blame. MySQL, the database Bugzilla uses for -storage, asks for a licensing fee if you're going to use it for non-internal -commercial usage. The license is cheap (170 euro), but support can -be expensive depending on the level of support you desire. There -is also a version of Bugzilla available at http://bugzilla.redhat.com which -runs over top of Oracle; that's a pretty expensive product, but Oracle -support and proven scalability may be worth it to you. -<br> -<p> -<hr WIDTH="100%"> -<center> -<h2> -<a NAME="BZINSTALLATION"></a>BUGZILLA INSTALLATION</h2></center> - -<center>or "Divide by cucumber error. Please re-install universe -and reboot."</center> - -<hr WIDTH="100%"> -<br><b><i>Q:</b> How do I download and install Bugzilla?</i> -<br><b><i>A:</i></b> The README included with Bugzilla documents the installation -procedures much more thoroughly than I can do here. You can always find -a current copy of the README in the distribution tarballs available at -<a href="http://www.mozilla.org/projects/bugzilla/">http://www.mozilla.org/projects/bugzilla/ -</a>. -This will eventually be documented in "The Bugzilla Installation Guide". -<p><b><i>Q:</i></b> <i>How do I install Bugzilla on Windows NT?</i> -<br><b><i>A:</i></b> That question is complex enough it deserves -<a href="#BZNT">its -own section</a>, below. -<p><i><b>Q: </b>Is there an easy way to change the Bugzilla cookie -name?</i> -<br><b><i>A:</i></b> At present, no. - -<p><i><b>Q: </b>I want to set up a test installation to try out new -changes. How do I copy over data from my real database?</i> -<br><b><i>A:</i></b> - -Copying the mysql files directly from one machine to another is likely -to confuse mysql. Its recommended to create a dump of the database -and to populate the new database from the dump. -<OL> -<LI> -Create a dump of the original database. -<BLOCKQUOTE><CODE> -%mysqldump bugs > ~/bugs.dump -</CODE></BLOCKQUOTE> - -<LI> -Copy the dump file to the new machine. - -<LI> -Blow away the contents of the current bugzilla database -on the test machine. -<BLOCKQUOTE><CODE> -%mysql<BR> -mysql> drop database bugs;<BR> -mysql> create database bugs;<BR> -</CODE></BLOCKQUOTE> - -<LI> -Import the bug database -<BLOCKQUOTE><CODE> -%mysql bugs < bugs.dump -</CODE></BLOCKQUOTE> - -</OL> - - -<p> -<hr WIDTH="100%"> -<center> -<h2> -<a NAME="BZCONFIGURATION"></a>BUGZILLA CONFIGURATION</h2></center> - -<center>or "make config. not war"</center> - -<hr WIDTH="100%"> -<br> -<blockquote> -<h3> -<a NAME="BZSECURITY"></a>SECURITY</h3> -</blockquote> -<b><i>Q:</i></b> <i>How do I completely disable MySQL security if -it's giving me problems (I've followed the instructions in the README!)?</i> -<br><b><i>A:</i></b> Run mysql like this: "mysqld --skip-grant-tables". -Please remember this makes mysql as secure as taping a $100 to the floor -of a football stadium bathroom for safekeeping. Before you plan to -put Bugzilla up for general consumption, you REALLY need to become familiar -with <a href="http://www.mysql.com/Manual_chapter/manual_Privilege_system.html#Privilege_system">MySQL -security</a>. -<p><b><i>Q:</i></b> <i>Are there any security problems with Bugzilla?</i> -<br><b><i>A:</i></b> Prior to 2.10, yes. For 2.10 and later, probably, -but we haven't discovered them yet.. You should upgrade to 2.10 and use -the following instructions from Chris Yeh's security advisory of 5/10/2000 -if you are running a previous version of bugzilla. Chances are good a lot -of these permissions issues will make it into checksetup.pl. -<br>It is recommended that you closely examine permissions on your Bugzilla -installation. Make sure you are not running mysqld as root. Included is -one person's examination of their local Bugzilla installation, and how -they secured it: -<p><tt><pre><font size=-1> I closed-up some of the all-writeable files -and directories. The code itself had to be modified to keep it from making -directories and files world-writeable again... Once this was done, I felt -confident that this install of bugzilla was running securely. (We don't -run ftp, and mysql doesn't run as root). The setup we have is that apache -runs as user 'nobody'. Directories being written into via CGI are therefore -owner.group==nobody.nobody and only read/writable by user nobody, not world-writeable -as before ... The *.cgi/*.pl/etc scripts (source) are owned by root.root -and we can prevent CGI execution and HTTPD reading of the scripts by doing -chmod go-rwx.... Finally, we prevent reading of the writeable directories -by HTTP. (The security of this could further be improved by running bugzilla -as user 'bugzilla' with same privs as 'nobody' but at least a different -user than the webserver). I did the following to secure our install:</font></tt> -<br><tt><font size=-1>(1) cd /home/httpd/bugzilla ensure all files owned -root.root (other than ones in 'shadow' and 'data').</font></tt> -<br><tt><font size=-1>(2) chmod go-rwx backdoor.cgi ; chmod go-rwx *.sh -; chmod go-rwx printenv.cgi ; chmod go-rwx 0CGI.pl ; chmod go-rwx *~* ; -chown -R nobody.nobody data ; chmod -R go-rwx data ; chown -R nobody.nobody -shadow ; chmod -R go-rwx shadow</font></tt> -<br><tt><font size=-1>(3) in emacs, in *.pl and *.cgi and processmail in -bugzilla dir</font></tt> -<br><tt><font size=-1>(etags *.cgi *.pl processmail) ... do: (tags-query-replace -"umask 0" "umask 077" nil)</font></tt> -<br><tt><font size=-1>(tags-query-replace "umask(0)" "umask(077)" nil)</font></tt> -<br><tt><font size=-1>(tags-query-replace "0777" "0700" nil)</font></tt> -<br><tt><font size=-1>(tags-query-replace "0666" "0600" nil)</font></tt> -<br><tt><font size=-1>(4) re-enable bugzilla with /home/httpd/bug-track.conf -set to:</font></tt> -<br><tt><font size=-1>--------------------</font></tt> -<br><tt><font size=-1>AddHandler cgi-script .cgi</font></tt> -<br><tt><font size=-1>#</font></tt> -<br><tt><font size=-1># setup ExecCGI'able directory alias from which we -run</font></tt> -<br><tt><font size=-1># "bugzilla" under URL "bugs"</font></tt> -<br><tt><font size=-1>#</font></tt> -<br><tt><font size=-1>Alias /bugs/ "/home/httpd/bugzilla/"</font></tt> -<br><tt><font size=-1><Directory "/home/httpd/bugzilla"></font></tt> -<br><tt><font size=-1>Options Indexes ExecCGI</font></tt> -<br><tt><font size=-1>AllowOverride None</font></tt> -<br><tt><font size=-1>Order allow,deny</font></tt> -<br><tt><font size=-1>Allow from all</font></tt> -<br><tt><font size=-1></Directory></font></tt> -<br><tt><font size=-1>--------------------</font></tt> -<br><tt><font size=-1>(5) add to /home/httpd/bug-track.conf (prevent cgi -from being</font></tt> -<br><tt><font size=-1>written into data or shadow directories, and prevent -contents from</font></tt> -<br><tt><font size=-1>being read):</font></tt> -<p><tt><font size=-1>--------------------</font></tt> -<p><tt><font size=-1><Directory "/home/httpd/bugzilla/data"></font></tt> -<br><tt><font size=-1>Options None</font></tt> -<br><tt><font size=-1>AllowOverride None</font></tt> -<br><tt><font size=-1>Deny from all</font></tt> -<br><tt><font size=-1></Directory></font></tt> -<p><tt><font size=-1><Directory "/home/httpd/bugzilla/shadow"></font></tt> -<br><tt><font size=-1>Options None</font></tt> -<br><tt><font size=-1>AllowOverride None</font></tt> -<br><tt><font size=-1>Deny from all</font></tt> -<br><tt><font size=-1></Directory></font></tt> -<p><tt><font size=-1>--------------------</font></tt> -<p><tt><font size=-1>(6) I noticed that my non-superuser-$PATH had wound -up in apache's GGI</font></tt> -<br><tt><font size=-1>environment... that $PATH included "." so that could -have been a security-exploit-in-waiting right there... so remember, when -restarting apache on servers, do (in tcsh anyways):</font></tt> -<br><tt><font size=-1>unsetenv *</font></tt> -<br><tt><font size=-1>prior to doing</font></tt> -<br><tt><font size=-1>apachectl stop</font></tt> -<br><tt><font size=-1><wait></font></tt> -<br><tt><font size=-1>apachectl start</font></tt> -</pre> -<p><i><b>Q:</b> I've implemented the security fixes mentioned in Chris -Yeh's security advisory of 5/10/2000 advising not to run MySQL as root, -and am running into problems with MySQL no longer working correctly.</i> -<br><b><i>A:</i></b> Mozilla.org had a problem getting enough file descriptors -once they stopped running mysql as root; they have many tables in their -database and had "shadowdb" turned on, which doubles the number of tables. -Terry mentioned in IRC: "I added the line "ulimit -n unlimited" to the -/bin/sh script in /etc/init.d that starts mysqld." That should fix ulimit -problems with MySQL. -<br> -<blockquote> -<h3> -<a NAME="BZEMAIL"></a>EMAIL</h3> -</blockquote> - -<p><br><i><b>Q:</b> I have a user who doesn't want to receive any more -email from Bugzilla. How do I stop it entirely for this user?</i> -<br><b><i>A:</i></b> Easy. Add his/her login name to "bugzilla_home/data/nomail". -One entry per line. It must match the login name exactly. -<br><b>UPDATE</b>: I'm not sure this works as advertised... -Anyone know of any bugs with this solution? -<p><i><b>Q:</b> I'm evaluating/testing Bugzilla, and don't want it to send -email to anyone but me. How do I do it?</i> -<br><b><i>A:</i></b> According to Terry, the *correct* way to do this is, -in editparams.cgi: "Go tweak the param for the mail text, replacing "To:" -with "X-Real-To:", and replacing "Cc:" with "X-Real-CC", and add a "To: -(myemailaddress)". This param file can also be manually edited bugzilla_home/data/params -(but is not recommended). -<p><b><i>Q:</i></b> <i>I want whineatnews.pl to whine at something more, -or other than, only new bugs. How do I do it?</i> -<br><b><i>A:</i></b> Try Klaas Freitag's excellent patch for "whineatassigned" -functionality. You can find it at <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=6679">http://bugzilla.mozilla.org/show_bug.cgi?id=6679</a>. -Realize that as Bugzilla progresses, this patch may go out of date. At -present, I know of no plans to integrate this functionality into the core -Bugzilla distribution. -<p><b><i>Q:</i></b> <i>I don't like/want to use Procmail to handle email -to bugzilla. What else can I use?</i> -<br><b><i>A:</i></b> Bugzilla can work with alternate MTA's/filters, -but there is no documentation how. -<p><b><i>Q:</i></b> <i>How do I set up the email interface to submit/change -bugs via email?</i> -<br><b><i>A:</i></b> Download the tarball or CVS and extract it (if applicable). -CD to the (bugzilla_home)/contrib directory, and read the README contained -therein. Seth will be pulling his changes (the bugzilla email submission -stuff) into the main tree sometime as soon as he gets the OK from the powers-that-be. -Procmail is included by default on most Linux distributions, and if you -use the bugzilla.procmailrc file as the .procmailrc for the user bugzilla -runs as, it works pretty quickly. -<br>My setup is a little different from the standard way of doing things. -Here's what I do: -<ol> -<li> -cd (bugzilla_home, wherever that is)</li> - -<li> -chmod 775 contrib</li> - -<li> -chmod 644 contrib/*</li> - -<li> -chmod 755 contrib/*.pl</li> - -<li> -chmod 777 data</li> - -<li> -chmod -R 775 data/mimedump-tmp</li> - -<li> -chmod -R 775 data/mining</li> - -<li> -vi /etc/aliases: add 'bugs: | "/usr/bin/procmail -m /etc/procmailrcs/bugs"'</li> - -<li> -cp /usr/local/bugzilla/contrib/bugzilla.procmailrc /etc/procmailrcs/bugs</li> - -<li> -chmod 775 /etc/procmailrcs/bugs</li> - -<li> -And, in my case, since we use Linux-Mandrake most everywhere (which includes -some extra security options), I also had to "ln -s /usr/bin/procmail /etc/smrsh/procmail. -smrsh is a way to prevent people from running any applications over Sendmail -unless you specify it in this directory. YMMV.</li> -</ol> -If you've followed the README, you should be good to go; send an email -to "bugs@my.host.name" and watch it work. -<p><b><i>Q:</i></b> <i>Email takes FOREVER to reach me from bugzilla -- -it's extremely slow. What gives?</i> -<br><b><i>A:</i></b> If you are using an alternate Mail Transport Agent -(MTA other than sendmail), make sure the options given in the "processmail" -script for all instances of "sendmail" are correct for your MTA. If you -are using Sendmail, you may wish to delete the "-ODeliveryMode=deferred" -option in the "processmail" script for every invocation of "sendmail". -(Be sure and leave the "-t" option, though!) This option is put into -the code to handle the massive mail delivery load bugzilla.mozilla.org -gets -- but most of us don't need it. We're lobbying to make it a -settable parameter. Realize if you turn this off, and plan on sending -more than a few hundred email messages a day, people may experience nasty -slowdowns when submitting changes to bugs because Sendmail insists on delivering -it *that instant*. -<p><b><i>Q:</i></b> <i>Email never reaches me from bugzilla changes! What -gives?</i> -<br><b><i>A:</i></b> Chances are really good Bugzilla expects "sendmail" -to live somewhere else than you have it installed. Make sure your "sendmail" -lives in, or has a symlink to, "/usr/lib/sendmail". -<br> -<blockquote> -<h3> -<a NAME="BZDATABASE"></a>DATABASE</h3> -</blockquote> -<b><i>Q:</i></b> <i>I've heard Bugzilla can be used with Oracle?</i> -<br><b><i>A:</i></b> <a href="http://bugzilla.redhat.com/">Red Hat Bugzilla</a> -works with Oracle. The current mozilla.org version takes some work, -though. -<p><b><i>Q:</i></b> <i>Bugs are missing from queries, but exist in the -database (and I can pull them up by specifying the bug ID). What's wrong?</i> -<br><b><i>A:</i></b> You've almost certainly enabled the "shadow database", -but for some reason it hasn't been updated for all your bugs. This is the -database against which queries are run, so that really complex or slow -queries won't lock up portions of the database for other users. You can -turn off the shadow database in editparams.cgi. If you wish to continue -using the shadow database, then as your "bugs" user run "./syncshadowdb --syncall" from the command line in the bugzilla installation directory -to recreate your shadow database. After it finishes, be sure to check the -params and make sure that "queryagainstshadowdb" is still turned on. The -syncshadowdb program turns it off if it was on, and is supposed to turn -it back on when completed; that way, if it crashes in the middle of recreating -the database, it will stay off forever until someone turns it back on by -hand. Apparently, it doesn't always do that yet. -<p><b>Q:</b> <i>I think my database might be corrupted, or contain invalid -entries. What do I do?</i> -<br>A: Run the "sanity check" utility (./sanitycheck.cgi in the bugzilla_home -directory) to see! If it all comes back, you're OK. If it doesn't -come back OK (i.e. any red letters), there are certain things Bugzilla -can recover from and certain things it can't. If it can't auto-recover, -I hope you're familiar with mysqladmin commands or have installed another -way to manage your database... -<p><b><i>Q:</i></b> <i>I want to manually edit some entries in my database. -How?</i> -<br><b>A:</b> There is no facility in Bugzilla itself to do this. It's -also generally not a smart thing to do if you don't know exactly what you're -doing. However, if you understand SQL you can use the mysqladmin utility -to manually insert, delete, and modify table information. Personally, I -hate dealing with big SELECT statements and such, so I use "<a href="http://www.phpwizard.net/phpMyAdmin/">phpMyAdmin</a>", -to do all my database administration. You have to compile a PHP module -with MySQL support to make it work, but it's very clean and easy to use. -There are other utilities that work, as well, but I am lacking URL's. -<p><b>Q:</b> <i>MySQL GPL edition doesn't seem to work...</i> -<br><b><i>A:</i></b> Right! It doesn't! It's too old. Download the latest -tarball or rpm from <a href="http://www.mysql.com/">www.mysql.com</a> if -you want this to work. -<p><b><i>Q:</i></b> <i>I think I've set up MySQL permissions correctly, -but bugzilla still can't connect.</i> -<br><b><i>A:</i></b> Try running MySQL from its binary: "mysqld --skip-grant-tables". -This will allow you to completely rule out grant tables as the cause of -your frustration. However, I do not recommend you run it this way on a -regular basis, unless you really want your web site defaced and your machine -cracked... -<p><b><i>Q:</i></b> <i>How do I synchronize bug information among multiple -different Bugzilla databases?</i> -<br><b><i>A:</i></b> Currently, there is no way to do this. However, a -discussion about this has raged on and off in the newsgroup -- feel free -to whip something up, put it out there, and see how it's received. We're -at the point where most folks are sick of discussion. If you can create -a working model with working code, that's 90% of the battle. -<p><i><b>Q: </b>I get bizarre errors when trying to submit data, -particularly problems with "groupset". What gives?</i> -<br>A: If you're sure your MySQL parameters are correct, you might -want turn "strictvaluechecks" OFF in editparams.cgi. If you have -"usebugsentry" set "On", you also cannot submit a bug as readable by more -than one group with "strictvaluechecks" ON. -<p><b><i>Q: </i></b> Even after I delete bugs, the long descriptions -show up? -<br><b><i>A:</i></b> Delete everything from $BUZILLAHOME/shadow. -Bugzilla creates shadow files there, with each filename corresponding to -a -<br>bug number. Also be sure to run syncshadowdb to make sure, if -you are using a shadow database, that the shadow database is current. -<br> -<br> -<p> -<hr WIDTH="100%"> -<center> -<h2> -<a NAME="BZNT"></a>BUGZILLA AND WINDOWS NT</h2></center> - -<center>or "Welcome to Microsoft, where we put the 'NT' in "CAN'T"!</center> - -<hr WIDTH="100%"> -<p>Right now, running Bugzilla under Windows NT is an extremely hairy process. -I'll provide the instructions below, but please don't ask me how it's done --- getting this working on NT involves a lot of patience, skill, and PFM -(Pure Fscking Magic). As far as I know, nobody has been able to get a recent -(2.8 or post) version of Bugzilla running on NT. If you know different, -or can provide updated instructions to those provided below, please email -<a href="mailto:mbarnson@excitehome.net">Matthew -Barnson</a> with details. -<br>These are hints straight out of the newsgroup discussions. I -can't offer much more editing or insight, since I don't manage Bugzilla -on any NT boxes. -<p><b><i>Q:</i></b> <i>What is the easiest way to run Bugzilla on NT?</i> -<br><b><i>A:</i></b> Remove NT. Install Linux. Slap a label on the box -that says "Windows NT." The boss will never know the difference, except -perhaps wonder why the machine isn't crashing anymore. -<p><b><i>Q:</i></b> <i>CGI's are failing with a "something.cgi is not a -valid Windows NT application" error. Why?</i> -<br><b><i>A:</i></b> Depending on what Web server you are using, you will -have to configure the Web server to treat *.cgi files as CGI scripts. In -IIS, you do this by adding *.cgi to the App Mappings with the <path>\perl.exe -%s %s as the executable. -<br>...or this tip from Microsoft's web site... -<br>"Set application mappings. In the ISM, map the extension for the script -file(s) to the executable for the script interpreter. For example, you -might map the extension .py to Python.exe, the executable for the Python -script interpreter. Note For the ActiveState Perl script interpreter, the -extension .pl is associated with PerlIS.dll by default. If you want to -change the association of .pl to perl.exe, you need to change the application -mapping. In the mapping, you must add two percent (%) characters to the -end of the pathname for perl.exe, as shown in this example: c:\perl\bin\perl.exe -%s %s" -<p><b><i>Q:</i></b> <i>Can I have some general instructions on how to make -this work?</i> -<br><b><i>A:</i></b> Sure. Your Mileage May Vary. Contact <a href="mailto:andrew_lahser@merck.com">Andrew -Lahser </a>for the patches mentioned. -<ol> -<li> -#!C:/perl/bin/perl had to be added to every perl file.</li> - -<li> -Converted to Net::SMTP to handle mail messages instead of /usr/bin/sendmail.</li> - -<li> -The crypt function isn't available on Windows NT (at least none that I -am aware), so I made encrypted passwords = plaintext passwords.</li> - -<li> -The system call to diff had to be changed to the Cygwin diff.</li> - -<li> -This was just to get a demo running under NT, it seems to be working good, -and I have inserted almost 100 bugs from another bug tracking system. Since -this work was done just to get an in-house demo, I am NOT planning on making -a patch for submission to Bugzilla. If you would like a zip file, let me -know.</li> -</ol> -<b><i>Q:</i></b> <i>Hmm, couldn't figure it out from the general instructions -above. How about step-by-step?</i> -<br><b><i>A:</i></b> Sure! Here ya go! -<ol> -<li> -Install IIS 4.0 from the NT Option Pack #4.</li> - -<li> -Download and install Active Perl.</li> - -<li> -Install the Windows GNU tools from Cygwin. Make sure to add the bin directory -to your system path. (Everyone should have these, whether they decide to -use Bugzilla or not. :-) )</li> - -<li> -Download relevant packages from ActiveState at http://www.activestate.com/packages/zips/. -+ DBD-Mysql.zip</li> - -<li> -Extract each zip file with WinZip, and install each ppd file using the -notation: ppm install <module>.ppd</li> - -<li> -Install Mysql. *Note: If you move the default install from c:\mysql, -you must add the appropriate startup parameters to the NT service. (ex. --b e:\\programs\\mysql)</li> - -<li> -Download any Mysql client. http://www.mysql.com/download_win.html</li> - -<li> -Setup MySql. (These are the commands that I used.)</li> - -<ol> -<br>I. Cleanup default database settings. -<br> C:\mysql\bin\mysql -u root mysql -<br> mysql> DELETE FROM user WHERE Host='localhost' AND User=''; -<br> mysql> quit -<br>C:\mysql\bin\mysqladmin reload -<p>II. Set password for root. -<br> C:\mysql\bin\mysql -u root mysql -<br> mysql> UPDATE user SET Password=PASSWORD('new_password') -<br> WHERE user='root'; -<br> mysql> FLUSH PRIVILEGES; -<br> mysql> quit -<br> C:\mysql\bin\mysqladmin -u root reload -<p>III. Create bugs user. -<br> C:\mysql\bin\mysql -u root -p -<br> mysql> insert into user (host,user,password) values('localhost','bugs',''); -<br> mysql> quit -<br> C:\mysql\bin\mysqladmin -u root reload -<p>IV. Create the bugs database. -<br> C:\mysql\bin\mysql -u root -p -<br> mysql> create database bugs; -<p>V. Give the bugs user access to the bugs database. -<br> mysql> insert into db (host,db,user,select_priv,insert_priv,update_priv,delete_priv,create_priv,drop_priv) -values('localhost','bugs','bugs','Y','Y','Y','Y','Y','N') -<br> mysql> quit -<br> C:\mysql\bin\mysqladmin -u root reload</ol> - -<li> -Run the table scripts to setup the bugs database.</li> - -<li> -Change CGI.pm to use the following regular expression because of differing -backslashes in NT versus UNIX.</li> - -<ul> -<li> -$0 =~ m:[^\\]*$:;</li> -</ul> - -<li> -Had to make the crypt password = plain text password in the database. (Thanks -to Andrew Lahser" <andrew_lahser@merck.com>" on this one.) The files -that I changed were:</li> - -<ul> -<li> -globals.pl</li> - -<li> -CGI.pl</li> - -<li> -alternately, you can try commenting all references to 'crypt' string and -replace them with similar lines but without encrypt() or crypr() functions -insida all files.</li> -</ul> - -<li> -Replaced sendmail with Windmail. Basically, you have to come up with a -sendmail substitute for NT. Someone said that they used a Perl module (Net::SMTP), -but I was trying to save time and do as little Perl coding as possible.</li> - -<li> -Added "perl" to the beginning of all Perl system calls that use a perl -script as an argument and renamed processmail to processmail.pl.</li> - -<li> -In processmail.pl, I added binmode(HANDLE) before all read() calls. I'm -not sure about this one, but the read() under NT wasn't counting the EOLs -without the binary read."</li> -</ol> -<b><i>Q:</i></b> <i>I'm having trouble with the perl modules for NT not -being able to talk to to the database...</i> -<br><b><i>A:</i></b> Your modules may be outdated or inaccurate... -<ol> -<li> -Try hitting http://www.activestate.com/ActivePerl</li> - -<li> -Download ActivePerl from there.</li> - -<br>After that: -<li> -go to your prompt</li> - -<li> -type 'ppm'</li> - -<li> -PPM> install DBI DBD-mysql GD</li> -</ol> -I reckon TimeDate and Data::Dumper come with the activeperl. You can check -the ActiveState site for packages for installation through PPM. [http://www.activestate.com/Packages/] -<p> -<hr WIDTH="100%"> -<center> -<h2> -<a NAME="BZUSE"></a>BUGZILLA USE</h2></center> - -<center>or "Keyboard: Device used for entering errors into computer"</center> - -<hr WIDTH="100%"> -<p><b><i>Q:</i></b> <i>How do I use "new email tech"?</i> -<br><b><i>A:</i></b> First, go to editparams.cgi and make sure the "newemailtech" -option is set to "on", then set the "new email tech" option in your personal -user prefs "on". -<p><b>Q:</b> <i>How do I make "new email tech" the default for my entire -site?</i> -<br><b><i>A:</i></b> You need to alter the user preferences table using -one of the tools mentioned in the <a href="#BZDATABASE">DATABASE section</a>. -Change the default value for "newemailtech" to "1", and change any user -values you think apply. -<p><b><i>Q:</i></b> <i>I'm confused by the behavior of the "accept" button -in the Show Bug form. Why doesn't it assign the bug to me when I accept -it?</i> -<br><b><i>A:</i></b> Right now, how this should behave is the subject of -considerable discussion on the mailing list and in the bug database. There -is a <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=25273">patch -</a>for -this, and a lot of talk. Tara has this to say: -<blockquote>"I think I put this in the main bug itself, but I have to admit -I *really* don't like the whole "accept" thing at this point. I especially -am completely against anything that changes the current functionality, -and am only moderately placated by the idea of seperate additional functionality. -IMHO Bugzilla is getting so kludgy that all we're doing is making things -harder and harder to understand and maintain, not to mention adding additional -fields to an already almost overwhelming query form. For now I'm going -to have to make people who want this suffer through sharing patches until -I come up with a course of action on it."</blockquote> -I'm working on a real patch for this now that allows you to select which -behavior you want vi editparams.cgi! -<p><b>Q: </b><i>How do I enable voting?</i> -<br><b><i>A:</i></b> Make sure you're using at least version 2.10. -It's available via editparams.cgi. -<p><i><b>Q: </b>I can't upload anything into the database via the -"Create Attachment" link. What am I doing wrong?</i> -<br><b><i>A:</i></b> The most likely cause is a very old browser -or a browser that is incompatible with file upload via POST. Download -the latest Netscape, Microsoft, or Mozilla browser to handle uploads correctly. -<p><i><b>Q:</b> Email submissions to Bugzilla that have attachments -end up asking me to save it as a "cgi" file.</i> -<br><b><i>A: </i></b> Right now, submissions via email only have one -mime-type "applications/octet-stream". Just save the file and look -at it in your favorite editor, you'll be fine (even though the name of -it will be "showattachment.cgi"). -<p><i><b>Q: </b> Argh, I forgot my password!</i> -<br><b><i>A:</i></b> No problem. Visit the query page, click -the "log in" button at the bottom, then just type in your email address -and click the "Email me a password" button. Your password will arrive -in your inbox in moments. -<br> -<p> -<hr WIDTH="100%"> -<center> -<h2> -<a NAME="BZKNOWNBUGS"></a>BUGZILLA KNOWN BUGS</h2></center> - -<center>or "These are all 'known bugs'. Whats the frickin' problem?"</center> - -<hr WIDTH="100%"> -<p><b><i>Q:</i></b> <i>What bugs currently exist in bugzilla?</i> -<br><b><i>A:</i></b> The answer is too long (and easily outdated) -to keep in this FAQ. However, bugzilla is made for this, so just -try <a href="http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Webtools&component=Bugzilla&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&order=bugs.bug_id">this -link</a>. -<p><b><i>Q:</i></b> <i>Groups don't quite work right yet...</i> -<br><b><i>A:</i></b> Correct. That's a current area of hacking. -You may want to check out Loki's version of Bugzilla for some patches that -support the group functionality you need. -<p><i><b>Q:</b> Why can't I set "target milestone" to something other -than a number?</i> -<br><b><i>A:</i></b> The concept of a target milestone was initially -that each group would have their own definition for what each target milestone -number is, but share a common pool of numbers. Unfortunately, this -concept has proven confusing for new and experienced users alike. -Someone needs to pick up the ball and run with "target milestone" so it -has the following features: -<ul> -<li> -Each Product can have milestone names independent of the other projects</li> - -<li> -Each Product can use numbers or names for arbitrary milestones</li> - -<li> -There must be a clean way to define these milestones without a ridiculously -complex params file</li> -</ul> -<i><b>Q: </b>Why shouldn't I delete bugs?</i> -<br><b><i>A:</i></b> If you allow bug deletion, you run the risk -of screwing up dependencies in your database. While these aren't -always critical, it's sometimes tought to repair. I recommend you -do not allow bug deletion. -<br> -<br> -<p> -<hr WIDTH="100%"> -<center> -<h2> -<a NAME="BZHACKING"></a>BUGZILLA HACKING</h2></center> - -<center>or "Who's this General Failure guy, and why is he trying to read -my hard drive?"</center> - -<hr WIDTH="100%"> -<p><b><i>Q:</i></b> <i>What's the best way to submit patches? What -guidelines should I follow.</i> -<br><b><i>A:</i></b> Tara summed this FAQ up nicely: -<blockquote>"Well, I guess I'd better answer this, as I'm the one who's -supposed to be in charge of this stuff... -<br>I say, if you have a patch that is a bug fix or feature enhancement, -log a bug and attach the patch. I've inherited almost 300 bugs from -the ownership transition, so I can't guarantee how soon I'll get to it, -but I'm steadily working my way through the bug list and trying to pay -special attention to all bugs that do come with patches. Secondly, if you'd -like faster feedback or better exposure, I'd post the bug number URL to -the newsgroup so more people can have a look and provide feedback, suggestions, -etc. That way I think all bases are covered. Speaking for myself -in trying to be a good module owner, getting a new bug makes sure I -<br>don't lose track of your patch, so this makes it easier for me."</blockquote> -<i><b>Q:</b></i> <i>What does the above mean for me when I want to -submit a bug?</i> -<br><b><i>A:</i></b> Follow this procedure: -<ol> -<li> -<a href="http://bugzilla.mozilla.org/enter_bug.cgi?product=Webtools">Enter -a bug</a> into bugzilla.mozilla.org for the "Webtools" product, "Bugzilla" -component.</li> - -<li> -Upload your patch as a unified DIFF (or new source file) by clicking "Create -a new attachment" link on the bug page you've just created, and include -any descriptions of database changes you may make, into the bug ID you -submitted in step #1.</li> - -<li> -Announce your patch and the associated URL (http://bugzilla.mozilla.org/show_bug.cgi?id=XXXX) -for discussion in the <a href="news://news.mozilla.org/netscape.public.mozilla.webtools">newsgroup</a> -(netscape.public/mozilla.webtools). You'll get a really good, fairly -immediate reaction to the implications of your patch, which will also give -Tara an idea how well-received the change would be.</li> - -<li> -If it passes muster with minimal modification, Tara will put it into CVS. -If you submit enough really good patches (I have no idea how much "enough" -is), you may be granted CVS write access.</li> - -<li> -Bask in the glory of the fact that YOU helped write the most successful -open-source bug-tracking software on the planet :)</li> -</ol> - -<blockquote> -<h3> -<a NAME="BZAPI"></a>API</h3> -</blockquote> -<b><i>Q:</i></b> <i>I want to add a new form or module to Bugzilla. -Where can I find API documention?</i> -<br><b><i>A:</i></b> Right now, there really is none. I plan -on writing copious documentation for what each file and module does, as -well how to program new .cgi's to use the functionality and present alternate -interfaces. Right now, use the source. -<p><b><i>Q:</i></b> What are the most-needed features? -<br><b><i>A:</i></b> Check out the Bugzilla Development Roadmap at -<a href="http://www.mozilla.org/projects/bugzilla/roadmap.html">http://www.mozilla.org/projects/bugzilla/roadmap.html</a> -<br> -<p> -<hr WIDTH="100%"> -<center> -<h2> -<a NAME="MAINTAINER"></a>MAINTAINER & THIS DOCUMENT</h2></center> - -<hr WIDTH="100%"> -<p><i><b>Q: </b>Why do you use this antiquated format for maintaining -the FAQ, instead of FAQ-O-Matic or (insert cool FAQ program here)</i> -<br><b><i>A: </i></b>I'm actively seeking a better way to maintain -this. It's easily maintainable in its current form, but as it grows -it will become much less so. I'm interested in more options, but -don't want to lose control of the FAQ or be subjected to a page that's -a nest of hyperlinks and unprintable. The FAQ-O-Matic tends to create -FAQ's that cannot be easily printed as one page, and not easily portable -to another format (particulary PDF). One must be able to maintain -the FAQ as a single, printable document; if you know of a good system that -will fit the bill, let me know. -<p><b><i>Q:</i></b> <i>Who are you?</i> -<br><b><i>A:</i></b> I'm Matthew P. Barnson, manager of Systems Administration -for <a href="http://www.excitestores.com">Excite Business Applications -</a>and -part-time Bugzilla hacker. -<p><b><i>Q:</i></b> <i>Why are you doing this?</i> -<br><b><i>A:</i></b> I have nothing better to do with my time! -<br> Seriously, I run a fairly large private Bugzilla database. -I felt the need for some documentation to help other SysAdmins run this -thing. There was nothing out there like it, so I decided to improve -what I'd written for internal documentation with more general questions -and release it to the public under the MPL. I feel like the Mozilla -Webtools are far more in need of good documentation and a major architectural -rewrite than they are more hacks to support more features. Since -I'm not qualified to write more than trivial hacks for Bugzilla if I were -to code, I figured doing some documentation would be A Good Thing. -<p><b><i>Q:</i></b> <i>How are you affiliated with <a href="http://www.mozilla.org">Mozilla.org</a>?</i> -<br><b><i>A: </i></b> I'm not, except I've been appointed the "Docs -Knight" for Bugzilla, and contribute documentation to other webtools. -<p><b><i>Q:</i></b> <i>Where do those lame quotes in each section -heading come from?</i> -<br><b><i>A:</i></b> Check out <a href="http://bugzilla.mozilla.org/data/comments">http://bugzilla.mozilla.org/data/comments</a>. -These are random quips added by people who use bugzilla. I find them -endlessly entertaining. -<p><i><b>Q: </b> What other documentation is available?</i> -<br><b><i>A: </i></b> I am personally attempting to address the numerous -documentation needs, including an Installation guide (based upon the README), -Administration Guide, Troubleshooting guide, Database Management Guide, -and Configuration Guide. -<br> -<p> -<hr WIDTH="100%"> -<center> -<h2> -THE END</h2></center> - -<hr WIDTH="100%"> -</body> -</html> |