You're not the only one. But I am not very interested. I'm not a 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 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.

[This was] 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. We always recommend that, if possible, you keep the path as /usr/bonsaitools/bin/perl, and simply add a /usr/bonsaitools and /usr/bonsaitools/bin directory, then symlink your version of perl to /usr/bonsaitools/bin/perl. This will make upgrading your Bugzilla much easier in the future. Obviously, if you do not have root access to your Bugzilla box, our suggestion is irrelevant.

Somebody needs to take the ball and run with it. I'm the only maintainer and am very pressed for time.

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. 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. 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: No enum types. All old enum types are now separate smaller tables. No bit wise operations. Not all databases support this so they were changed to a more generic way of doing this task 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 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. 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. 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. 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. 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 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. 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.

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. 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.

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.).

bugzilla-daemon: "|/usr/local/bin/bugzilla/contrib/bug_email.pl"

"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"