Bugzilla Integration Design Meeting, 2000-11-17

1. Introduction

This is a record of a meeting in which Nick Barnes presented his design for the Bugzilla integration to Gareth Rees and Richard Brooksby.

The readership of this document is the project staff.

This document is not confidential.

2. Design

Figure 1. The whiteboard form the meeting showind the overall structure

Figure 1 shows the overall structure of Bugzilla, consisting of:

1. the Bugzilla CGI scripts in Perl;
2. the web server providing the interface to Bugzilla;
3. the MySQL database management system;
4. the database containing the records being tracked by Bugzilla;
5. the Unix shell used to run administration scripts;
6. the replicator's connection to the MySQL DBMS.

Nick described how the Bugzilla database schema is pretty much fixed and hard coded in to the CGI. There are some parameters which change it a bit (e.g. enabling voting). Bugzilla can also have a "shadow database" which is read-only and used to speed up web access.

Nick has written up the Bugzilla database schema [ref?]. We will make this document available to the Bugzilla team. There are two important tables containing bugs and profiles for users. Bug descriptions go in a separate table related to the bugs table. In general in Bugzilla, auxillary data is stored in separate tables and related to the main table.

The integration will follow this pattern. We'll add a table called "p4dti_something" keyed on the bug id which has replicator stuff in it: rid, sid, jobname, action.

Why not add columns as in TeamTrack?

1. There may well be code out there that assumes things about the columns in the tables, even if the Bugzilla distribution code doesn't. We want to avoid modifying the Bugzilla base code for lots of reasons, but, mainly ease of installation (requirement 63), and ability to update integration to work with new versions of Bugzilla (requirement 32, requirement 30).
2. It's easier to uninstall the integration by removing tables, rather than modifying the existing schema again (requirement 64).
3. We want to be able to modify our own tables without changing the timestamps in the bugs table, so that the e-mail notifications etc. continue to work properly. In other words, we want to separate modifications made by the replicator from modifications made by ordinary users.
4. In future, some DMBSs might not easily allow adding of columns.
5. Bugzilla tends to use auxillary tables, so its consistent with the design.
6. We would've liked to have added a table in TeamTrack, but it's not supported.

The replicator will contain:

1. A MySQL abstraction layer, so that it can cope with a future Bugzilla based on other databases without too much effort. This layer is itself based on the Python Database API. The top interface to the layer is essentially like the Python Database API except that it hides MySQL specific things like column types when creating tables.
2. A Bugzilla module uses the MySQL abstraction to provide a Bugzilla-specific interface to bugs, etc. in a Bugzilla-specific fashion.
3. The dt_bugzilla class will be a subclass of defect_tracker analogous to dt_teamtrack.
4. The replicator, Perforce interface, and so on will be shared with the TeamTrack integration.

Perforce to Bugzilla user mapping will be done using e-mail addresses.

How is your interface to Bugzilla going to tell when bugs have changed? It's going to use the timestamp. It will record the last value in the p4dti table and use the modification date in the bugs table.

How will it distinguish its own changes from changes made by other people? With entries in the p4dti table saying "I changed it".

Will you do changelists and fixes? New tables will be added, related to the bugs table. The Bugzilla CGI will need to be modified to display the information and hyperlink it to a Perforce web interface. These tables will be replicated as with TeamTrack.

We probably don't need a separate Bugzilla user for the replicator, unlike the TeamTrack integration. The replicator can connect to the MySQL database just like the Bugzilla CGI does. It's the CGI which enforces all the workflow restrictions and user auditing, and the replicator won't be going through the CGI.

The Bugzilla modules in the replicator will have to duplicate the permissions logic enforced by the Bugzilla CGI in order to enforce it in Perforce.

Nick talked about how the replicator would create Bugzilla users on demand. Richard said that replicator probably shouldn't create new users or new bugs or other new entities in the defect tracker. The person managing Bugzilla might need control over users who can access it, and we wouldn't want spurious new users created because of errors in e-mail addresses in Perforce. Creating bugs from Perforce is a low priority requirement, judging from the feedback we've had and the alpha programme [RB 2000-11-04]. We expect the workflow to come in through the DT in most cases.

The Bugzilla integration will need to write a log when modifying the Bugzilla schema.

A. References

B. Document History

Copyright © 2000 Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.