PERFORCE DEFECT TRACKING INTEGRATION RELEASE NOTES FOR RELEASE 1.0.6 Gareth Rees, Ravenbrook Limited $Date: 2001/03/25 $ CONTENTS 1. Introduction 2. Supported configurations 3. Getting support 4. Project contacts 5. What's new 5.1. What's new in release 1.0.6 5.2. What was new in release 1.0.5 5.3. What was new in release 1.0.4 5.4. What was new in release 1.0.3 5.5. What was new in release 1.0.2 5.6. What was new in release 1.0.1 5.7. What was new in release 1.0.0 A. References B. Document history 1. INTRODUCTION These are the release notes for release 1.0.6 of the Perforce Defect Tracking Integration (P4DTI). The P4DTI connects your defect tracking system to Perforce, so that you don't have to switch between them and enter duplicate information about your work. It also links changes made in Perforce with defect tracker issues, making it easy to find out why a change was made, find the work that was done to resolve an issue, or generate reports relating issues to files or codelines. For instructions on installing the P4DTI, see the product readme (readme.txt). For up-to-date information about releases of the P4DTI, see the product information page . From there you will find links to the latest releases, including reports of defects found. If you want to adapt or extend the P4DTI, please go to the product information page and download the Integration Kit. It contains full source code and documentation to help you. The readership of this document is anyone who wants to download and use the Perforce Defect Tracking Integration. This document is not confidential. 2. SUPPORTED CONFIGURATIONS This release supports: - Perforce 2000.2 on any platform; - TeamTrack 4.5 running on Windows NT 4 or Windows 2000; - Bugzilla 2.10 on Red Hat Linux 6.2 or Solaris using MySQL The Bugzilla integration may work on other operating systems, but has not been tested. 3. GETTING SUPPORT For problems relating to Perforce or the P4DTI in general, contact Perforce Support by writing to or see the technical support page at for contact information. For problems relating to TeamShare, contact TeamShare Technical Support by writing to or see the support page at for contact information. Bugzilla is not supported by any one person or organization. Consult the documentation that came with Bugzilla, or visit . 4. PROJECT CONTACTS You may want to join the p4dti-discussion mailing list. The goals of the list are: 1. to provide feedback to the project on requirements, design, implementation, etc.; 2. to allow people to exchange information and experience with using and adapting the project; 3. to keep people informed about project progress. To join, send a message with the word "subscribe" in the _body_ to or send the word "help" for general information. Please note that the mailing list will be archived and the archive may be published. 5. WHAT'S NEW This sections lists defects that have been fixed. 5.1. WHAT'S NEW IN RELEASE 1.0.6 CRITICAL job000270: Can't fix job owned by user (None) in the TeamTrack integration If an issue has no owner in TeamTrack (and therefore the owner of the corresponding job is (None) in Perforce) then you can't transition the job by fixing it. The replicator is unable to replicate the change to the job and it overwrites the job with the issue. 5.2. WHAT WAS NEW IN RELEASE 1.0.5 The following defects were fixed between release 1.0.4 and release 1.0.5. CRITICAL job000261: Bugzilla patch and text files are missing from the RPM installation The RPM for Linux doesn't include the Bugzilla patch file, readme.txt, release-notes.txt, or license.txt files. The Bugzilla patch file is critical, as Bugzilla integration won't work without it. ESSENTIAL job000263: Bugzilla: P4DTI doesn't restart on reboot A P4DTI installed on Linux using the P4DTI RPM will not automatically restart when the system is rebooted. 5.3. WHAT WAS NEW IN RELEASE 1.0.4 The following defects were fixed between release 1.0.3 and release 1.0.4. ESSENTIAL job000254: AG claims TeamShare support provide licences The AG tells people to contact TeamShare support to get a TeamTrack licence for the replicator. In fact, they should contact their TeamShare sales representative, as it's sales who issue licences. OPTIONAL job000257: AG uses wrong words when talking about Perforce licences and support AG section 3.2.1 claims: "A daemon license is a license for an automatic process, rather than a person. Perforce provides daemon licenses free of charge; contact Perforce technical support to get one." 'daemon license' should be replaced with 'background user license'. This is consistent with Perforce terminology. 'Contact Perforce technical support' should be replaced with 'Contact Perforce Customer Service.' 5.4. WHAT WAS NEW IN RELEASE 1.0.3 The following defect was fixed between release 1.0.2 and release 1.0.3. ESSENTIAL job000251: Known issues included in release notes Perforce ask that the list of known issues is not included in the release notes for the software. 5.5. WHAT WAS NEW IN RELEASE 1.0.2 The following defects were fixed between release 1.0.1 and release 1.0.2. CRITICAL job000200: No supported TeamTrack release works with integration There's no officially supported TeamTrack release that works with the integration. job000234: jobs from Bugzilla get wrong name A job replicated from a new Bugzilla bug gets the bug number N (readable-name()) as the job name instead of "bugN" (corresponding_id()). job000235: New Bugzilla bugs may cause conflict email If a Bugzilla bug is created or changed in the same second as the start of a replicator poll, it may be replicated on two consecutive polls. This will cause a conflict email to be sent on the second poll (as the replicator is also then trying to replicate the new job back to Bugzilla because it can't tell that the job change was made by itself; see job000016). job000236: Bugzilla table grows without bound The P4DTI keeps a table in the Bugzilla database called p4dti_replications which grows quite fast (hundreds of K per day). There is a function to delete redundant rows from this table (bugzilla.delete_complete_replications()) but it is never called. job000237: Bugzilla logger breaks on Windows. The Bugzilla logger tries to log to the syslog. It can't manage that on Windows because there isn't one. There's code in logger.py to get around this but it falls over because of numbers of arguments in a class method. job000238: Broken python in bugzilla.py Bugzilla.py has a function convert_type() which takes three arguments. The third is a tuple. The existing code pulls the tuple apart in the argument list. That doesn't work in the Python implementation of one beta tester. job000241: some MySQL versions break table description A user running MySQL 3.22.32 on Linux couldn't run the P4DTI because the results of the 'describe' SQL command had a different number of columns from that on the development system (also MySQL 3.22.32!?). ESSENTIAL job000233: When you submit a new issue to TeamTrack it overwrites the issue When you submit a new issue in TeamTrack, then the replicator sets up that issue for replication and replicates it to Perforce. Then the next time it polls, it thinks that the issue and the corresponding job have changed, so it overwrites the jobs with the issue. This also happens when you run the replicator for the first time, if there are issues modified since the start_date. All the issues get replicated and then overwritten. OPTIONAL job000216: readme.txt mentions beta sites The readme.txt mentions particular beta sites (in the known issues section). Probably we should avoid this. job000227: AG doesn't have Bugzilla error messages Section 11.2 of the AG lists and explains P4DTI error messages. Most of the error messages produced by the Bugzilla integration are not mentioned in this section. 5.6. WHAT WAS NEW IN RELEASE 1.0.1 The following defects were fixed between release 1.0.0 and release 1.0.1. CRITICAL job000027: There are outstanding defects that were found in release 0.3.0. job000217: readme.txt has too much detail of fixed bugs It's good to identify fixed bugs in the readme.txt, but if we do so verbosely then even mildly impatient readers will never get to the 'known bugs' section, which is arguably much more important. job000218: readme.txt has a confusing date at the top The readme.txt file says "Richard Brooksby, Ravenbrook Limited, 2000-10-30", right at the top, because it conforms to our standard document style. This will be very confusing to users, and may well put people off in time (e.g. when it still says this in late 2002, and users download it and say "eeek, this hasn't been maintained for two years"). job000221: Refreshing Perforce jobs fails in Bugzilla integration A user of 0.5.1 attempted to refresh Perforce jobs, but that failed with the following error: File "bugzilla.py", line 192, in sqlquote raise error, ("sqlquote given non-string %s." % str(value)) P4DTI Bugzilla interface error: sqlquote given non-string None. ESSENTIAL job000135: Replicator makes no more progress if replication to Perforce fails If replication from the defect tracker to Perforce fails for whatever reason, the replicator gets into a loop where it keeps e-mailing the administrator. job000166: May fail with later MySQLdb versions We may fail with later MySQLdb versions, in particular 0.3.0 which I believe is gaining popularity. We haven't tested this. We should test and make any appropriate fixes. If there are serious incompatibilities, we should at least test the version (MySQLdb.__version__). It may not be appropriate to require 0.2.2, as the MySQLdb version is a system-wide property and users may have other requirements forcing them to use 0.3.0. Also, operating systems and Python or MySQL packages are likely to be distributed with 0.3.0 (or above) in future. job000174: The AG doesn't tell you how to upgrade from the beta A small number of sites will be running a beta release like 0.4.2 or 0.5.1. When release 1.0.x comes out they will naturally want to upgrade. But the AG doesn't have any instructions telling them how to do this. job000188: tTrack integration fails with non-ASCII characters The tTrack integration does not cope with non-ASCII characters. For instance, "é" (character 0xe9). If this character is placed in a tTrack field, it gets into Perforce as "˙ffffffffffe9". Note that the first character is 0xff. Note also that the number of f's seems to depend on the exact platform: it's four on sandpiper (suggesting a 24-bit encoding) and ten on the reporting user's machine (suggesting a 48-bit encoding ?!). This encoding also appears in the log output; I don't think the P4DTI is doing it. Going the other way, putting "é" into a Perforce job causes the P4DTI to fail when trying to update tTrack (no message from the TeamShare API). job000191: Admin can't easily find release when contacting support In the AG we tell the administrator to report which release of P4DTI they are using. But how do they find this out? The documentation isn't clear and the program doesn't report it. job000194: tTrack states include tSupport states tSupport and tTrack both have states. When replicating from tTrack, the jobspec status field includes tSupport states, which are not possible for tTrack cases. This is not ideal. job000195: keyword translation is too conservative We translate keywords (items for Perforce job fields of type 'word') by using a hexadecimal escape %xx for characters other than [a-zA-Z0-9(),.?!-]. This is very conservative, and rules out a number of characters commonly used in defect trackers. We also translate the space character ' ' into the underscore character '_'. This has the problem that we do not escape underscores, so underscores in a defect tracker become underscores in Perforce and then translate back to spaces. We need a translator which is (a) bijective, (b) less conservative, and hopefully (c) less obfuscating. job000215: The replicator can send out mail bombs The replicator can get stuck in a loop where it sends e-mail to the administrator every 10 seconds (or whatever the poll_period is). This is very unfriendly. Not only that, the e-mail message can double in size each time because each message includes the formatted_traceback from the previous message. job000219: Existing jobs in Perforce may become unusable when the jobspec is changed When the P4DTI starts up for the first time, it changes the jobspec without checking to see whether any jobs are present. These jobs may become unusable when the jobspec is changed. job000222: Deleting fix causes replicator to crash A user tried out "p4 fix -d ...". The Bugzilla integration crashed with the following error: File "bugzilla.py", line 482, in delete_fix ('bug_id = %d and changelist = %d ' TypeError: not enough arguments; expected 4, got 3 job000225: If you "p4 fix" when there's no closed state, the replicator can't replicate When you do "p4 fix -c CHANGE JOB" then Perforce sets the status of the job to "closed". If "closed" is not a legal status in Perforce then the replicator can't get at the job any more, so it fails to poll. job000229: The readme is too hard to use The readme.txt is too hard to use. The lists of fixed and open issues are too long; they should be in a file of their own (release-notes.txt). job000230: Messages from the replicator refer to non-existent sections of the manuals Messages from the replicator refer the reader to sections of the UG and AG. But sometimes these sections don't exist. 1. When a job is overwritten, the replicator refers you to "section 2.5 of the P4DTI User Guide". 2. Tooltips for P4DTI-filespecs and P4DTI-action refer you to section ? of the Administrator's Guide. OPTIONAL job000052: Likely problems not in troubleshooting section Likely errors: 1. can't login: did you set the user name in TeamTrack to match the replicator id? 2. run out of users in Perforce? have you changed the replicator id recently? If so, make sure you delete the old Perforce user for the replicator. job000167: Released manuals should be on the website The released manuals are currently not available on the website (except by downloading and installing a release). This has several undesirable consequences. For instance, users browse the master or version manuals, which do not reflect the release which they have downloaded. Also it makes it impossible to give a URL into a released manual. job000208: TeamTrack integration doesn't provide a .reg file It's error prone to tell people to use regedit to set the "VC Integration" registry key. It would be better to provide a .reg file which people can double-click on to set the registry key. job000210: Bugzilla states/resolutions with spaces in them cause broken jobspec If the Bugzilla database schema is altered so that states and resolutions have spaces in them (this is legal in MySQL) then the replicator generates a broken jobspec. job000216: readme.txt mentions beta sites The readme.txt mentions particular beta sites (in the known issues section). Probably we should avoid this. job000223: Quote in change comment terminates display in TeamTrack A quote character (single or double) in a change comment terminates the display of that comment in the "Perforce fixes" table in TeamTrack. job000226: Newlines don't show up in change descriptions in TeamTrack Newlines in change descriptions don't show up in the "Perforce fixes" table. Instead, lines are placed adjacent to each other. job000232: Log and e-mail messages are confusing if jobname is different from the issue name Log messages and e-mail messages describe an issue using the name of the corresponding job. This is OK when they are the same (which is the usual case), but misleading when they are not (which could happen if you've migrated your jobs and kept the jobname). NICE job000171: AG should note broken MySQL versions MySQL 3.23.29-gamma and 3.23.29a-gamma are broken, in that they stop Bugzilla logins from working. We should note these in the Prerequisites section of the AG. 5.7. WHAT WAS NEW IN RELEASE 1.0.0 The following defects were fixed between release 0.5.1 and release 1.0.0. CRITICAL job000181: Assertion failure in translate_1_to_0 If an optional field in Perforce has no value, then a field translator may fail with an assertion error. job000190: Connection to TeamTrack hangs for several minutes When release 0.4.2 attempts to connect to TeamTrack 4407, it hangs for several minutes before connecting. job000205: Configuration is still too difficult The Administrator's Guide is too hard to use. Administrators are busy people and don't read documentation, not even the very nice documentation that we've put so much effort into. ESSENTIAL job000006: TeamShare API error reporting is inadequate. When TeamTrack refuses to update or transition an issue because a user doesn't have the privilege to do so, it raises an error but provides only an empty error message. The replicator can't provide any information to the user to explain why the operation failed. job000033: Incompatible with other TeamShare API programs The P4DTI is incompatible with other TeamShare API programs because changes made by other TeamShare API programs are not replicated. The replicator has no reliable way of distinguishing its changes to TeamTrack from other users' changes in TeamTrack; this is because all API users show up as user 0 in the CHANGES table. So changes made in TeamTrack by other API users (e.g. other integrations or scripts) will not be replicated accurately. job000048: Consistency checking of the configuration is inadequate Consistency checking of the configuration needs to be much stronger, to catch problems so that they don't affect the replicator when it's in use. job000075: No automatic check of configuration How do you tell if the configuration is correct? There should be automatic checking of the configuration. See e-mail "Checking the configuration automatically" for some ideas. job000082: AG has no training and documentation section The AG has no guidance on training and documentation for users. job000092: Long descriptions aren't replicated by Bugzilla integration In Bugzilla, bugs have short descriptions (called "Summary" in the web interface) and long descriptions. Each bug may have many long descriptions; they carry a timestamp and are displayed in date order. They also carry user names. Currently these long descriptions are not replicated. Perhaps they should be; the short description can be too short and/or misleading. Note that it is not possible to edit or delete long descriptions from the Bugzilla web interface; only to submit new descriptions to be appended. job000093: Can't replicate other Bugzilla fields Bugzilla bugs have loads of fields. We only replicate a small number of them. We don't support the "replicated_fields" parameter in the Bugzilla configuration. job000103: Can't easily add to replicated_fields list The configurator doesn't cope if you change the replicated_fields. The P4DTI administrator can't add a new field to the replicated_fields list (except at the end of that list) because the new field will get a Perforce field number that was previously used by another field. So the data that was previously in that other field gets captured by the new field. If you have used the automatic configuration generator and you edit the replicated_fields list, fields probably get the wrong values in Perforce, because the generated jobspec's field numbers probably don't match the old values. job000109: Can't get at Perforce information from TeamTrack TeamTrack lists associated changes for each issue, but you can't easily get at any more details without going to the Perforce interface. It's inconvenient, and not every TeamTrack user will even be licensed to go to the Perforce interface. job000112: Can't easily replicate by project It's hard to set the replicator to replicate only those issues in a particular project or group of projects. job000116: Bugzilla integration doesn't do enough checking The Bugzilla integration does hardly any checking, either of the configuration or of data encountered during replication. This is in contrast to the TeamTrack integration, which now does quite a lot of checking. job000117: Jobview and job filter confused in the UG The UG says that the list of jobs displayed in the GUI dialogs is affected by the users jobview. This isn't true. It's the job filter that's used. The jobview only affects the command line interface. job000122: Server failures aren't handled gracefully If the Perforce server or the defect tracker is down, the replicator produces unhelpful error messages and e-mails to the administrator. job000138: "Add Job Fix" always sends jobs to "closed" The "Add Job Fix" command in the Perforce Windows GUI always sends a job to status "closed". Users will want to link changes using other keywords. job000141: Can't add to replicated_fields list The P4DTI administrator can't add a new field to the replicated_fields list (except at the end of that list) because the new field will get a Perforce field number that was previously used by another field. So the data that was previously in that other field gets captured by the new field. job000155: Bugzilla integration doesn't send mail Bugzilla sends lots of email, when bugs change. We don't do that. Bugzilla has a Perl script called "processmail", which it runs whenever a bug changes. It analyses the bug activity and may send mail to one or more Bugzilla users describing that activity. We don't do this, or emulate it, so Bugzilla bugs will be changed by the replicator without email being sent out. job000156: Pending changelists aren't clearly indicated as such in Bugzilla You can't tell the difference in the P4DTI section of the Bugzilla bug form between a pending changelist and a submitted one.Ę This means that you might mistakenly think that work has been done when in fact it is only pending and may later be reverted. job000157: Improper installation on Linux The integration is distributed as a simple tarball on Linux and doesn't install anywhere in particular. The AG says to put it in the administrator's home directory for the moment, which isn't good enough. job000172: Replicating some fields can break Bugzilla Some fields can not be changed using the Bugzilla interface, or only changed in highly restricted ways. Now that these fields can be replicated into Perforce, we should restrict changing these fields in Perforce. For instance, the 'votes' field can only be changed by voting, which involves checking and updating other fields in other tables and may have other side-effects. For another instance, the 'product', 'version', and 'component' fields must be keys into other tables. For a third instance, the created_ts field is never updated. job000173: Wrong Perforce server version causes installation to fail mysteriously If you have the wrong Perforce version (2000.1 or earlier) then installation will fail, with an error like this: "Perforce error: Error in job spec specification. Missing required field 'Values-State'." It should instead say something like "Perforce release not supported; changelevel NNNNN required." job000178: AG doesn't give advice on making problem reports The AG doesn't give advice on how to get effective support for the P4DTI. Typically someone e-mails a section of their P4DTI log -- for example, the error message at the end. This is rarely enough information to track down the problem. job000180: bugzilla_user is confusing. Many people find the bugzilla_user configuration parameter confusing. We should get rid of it and use the replicator_address parameter in its place. job000182: Elapsed time fields aren't replicated properly Date fields in TeamTrack have a "display type" which can be "Date only", "Date and time", "Time only" and "Elapsed time". The repicator copes well with the first two, but poorly with the second two (an elasped time of 10 hours in TeamTrack becomes a date of 1971/01/01 10:00:00 in Perforce). job000184: Bugzilla integration doesn't work if your database is not called 'bugs' If your Bugzilla database is not called 'bugs', then P4DTI tries to connect to 'bugs' anyway. So it doesn't work! job000185: python RPMs no good The Python 1.5.2 RPMs are no good for building the MySQLdb interface. In the AG we offer the Python 1.5.2 RPM. This is insufficient on its own to build the interface (because it doesn't have the header files). There is a python-devel RPM which does include header files, but for some reason the MySQLdb 0.2.2 and 0.3.0 interfaces don't compile out of the box with it. Building python 1.5.2 from the tarball distribution works OK, as long as you include the optional syslog module (by uncommenting the syslog line from Modules/Setup before running make). job000186: AG suggests python RPM which is insufficient MySQLdb can't be built using just the python RPM linked to from the AG. Our users need to build and install MySQLdb. To build it they need the python 1.5.2 header files. The python RPM linked to from the AG doesn't have any header files. They are contained in a python-devel RPM. However, the python-devel-1.5-2 RPM which we installed on swan (which may have downloaded from ftp.python.org; www.python.org does not now link to any RPMs for python 1.5.2) provides header files which are not quite right for building MySQLdb. I haven't dug very deeply here. I managed to build MySQLdb 0.2.2 by editing its source code. This is not very satisfactory. For MySQLdb 0.3.0 I also had problems. I resolved these by uninstalling the python and python-devel RPMs and building python from the sources (python-1.5.2.tar.gz). The optional syslog module is required by the P4DTI, so I had to edit Modules/Setup before running make. We need to fix the prerequisites section of the AG so that users get a python environment on which they can build MySQLdb and run the P4DTI. job000187: Creating Bugzilla tables twice We call bugzilla.create_p4dti_tables() twice on startup; once when making a bugzilla.bugzilla in configure_bugzilla and once when making a dt_bugzilla.dt_bugzilla in init.py. We can remove the call from inside dt_bugzilla.__init__. job000189: replicated_fields can't be changed without replicating all jobs In section 10 of the prepared manuals we tell people to run the refresh script if they change the replicated_fields parameter, but this forces all issues to be replicated, which they may not want. job000198: We don't check that bugzilla_directory works The configuration parameter bugzilla_directory names a directory in which the P4DTI will find a script called 'processmail'. The P4DTI runs this script after it changes a Bugzilla bug, and it sends email to Bugzilla users just as if the bug was changed through the Bugzilla web interface. We do not currently check that this parameter names a directory, or that the directory it names contains a processmail script. If either of these things is false, the P4DTI will fail to invoke the processmail script. job000199: Auxiliary scripts send e-mail The auxiliary scripts, check.py and refresh_perforce.py, send e-mail to the administrator saying that the replicator is starting up. They shouldn't do this, because it's unnecessary and the message is not true. job000202: Errors from Perforce not reported well Some Perforce errors are reported only as "The Perforce client exited with error code %d. Is the server down or the server address incorrect?" This provides little help in tracking down the problem. job000204: Issue owned by non-existent Perforce user causes crash If the Perforce server is running without any spare licences, then when the replicator tries to overwrite a job whose owner is a user that doesn't exist in Perforce, then you get the error message "Can't create a new user - over licence quota". job000212: TeamTrack 4.5 not supported The meaning of the arguments to TSServer::AddField() have changed in TeamTrack 4.5, which means that the new fields aren't be properly added to the CASES table. job000214: No way of controlling the poll period There's no easy way for the administrator to control the poll period. If 10 seconds gives performance problems then there should be a way of increasing the delay. OPTIONAL job000024: "\012" in fixes table in TeamTrack Change descriptions in the "Perforce fixes" section of a TeamTrack case description display the octal escape "\012" as those four characters, rather than as a newline (ASCII 10). job000032: Deletion of fixes and filespecs in TeamTrack may cease to work in future releases. Deletion of fixes and filespecs from the TeamTrack interface is correctly replicated to Perforce at present. But this depends on an undocumented feature of TeamTrack and so may cease to work when new releases of TeamTrack appear. job000101: Different transitions for different issue types may confuse the replicator In TeamTrack, different issue types (bugs, enhancements, etc) may have different workflows: that is, certain transitions may be enabled for some issue types but not for others. The replicator doesn't take this into account and so may pick the wrong transition, which means that the transition may fail. It may happen that the replicator can't transition any issues for this reason. job000160: 'closed' doesn't map to 'RESOLVED' in the Bugzilla integration The 'closed' status for Perforce jobs is special: p4 fix without a -s flag will cause a transition to 'closed'. The natural status for this to translate to in Bugzilla is 'RESOLVED': engineers should make bugs RESOLVED when they resolve them. But currently 'closed' in Perforce translates to 'CLOSED' in Bugzilla: to move a bug to 'RESOLVED', Perforce users must do 'p4 fix -s resolved'. Perforce users will want to move jobs to 'RESOLVED' often but to 'CLOSED' rarely. Using 'p4 fix' without '-s' will usually cause the replicator to reject the update because there are few legal transitions to 'closed'. job000163: jobspec fields too small for Bugzilla. The replicator makes a new Perforce jobspec. The "assigned_to" field has size 32. This must in fact be large enough to hold a Bugzilla login_name (from the "profiles" table in Bugzilla), which is varchar(255). The same may apply to other jobspec fields. job000165: Bugzilla configuration parameters are not checked. We don't check the Bugzilla configuration parameters. For instance, we don't check that dbms_port is a number, or dbms_host is a string, or that bugzilla_user is an email address. The result is that if a user sets a configuration parameter incorrectly, or leaves it unset, they may get a very obscure internal error from, for instance, MySQLdb. job000169: Change numbers are links in TeamTrack even when no changelist URL has been specified If changelist_url is None in the configuration, then changelist numbers are still links in the table of fixes in TeamTrack, but they don't link to anywhere sensible. job000170: Replicator may be unable to send e-mail if the default replicator_address is unchanged The file config_bugzilla.py says replicator_address = 'p4dti-%s' % rid. Ravenbrook's SMTP server allows the replicator to send e-mail from this address, but not all SMTP servers allow this. job000193: Bugzilla integration fails if DateTime module is installed The Bugzilla integration breaks if the Python DateTime module is installed on the P4DTI server system. The Python DateTime module is a third-party module for creating and manipulating dates and times. If it is present, MySQLdb uses DateTime types for time fields (date, time, datetime, and timestamp). However, this MySQLdb/DateTime combination breaks when a MySQL field contains a zero value (e.g. "0000-00-00 00:00:00"). This happens in Bugzilla (e.g. the 'lastdiffed' field of a new bug). We have not tested the P4DTI with the DateTime module at all; it is possible that using it causes other problems even if zero datetimes are not present. I have reported this problem to the author of MySQLdb, Andy Dustman . NICE job000161: Replicator appears to hang When the replicator starts up for the first time, it prints some log messages and then stops. This is disconcerting to the user, as you can't tell if it's hanging or waiting. job000168: Easy to set dbms_port to a string. It's easy to set the configuration parameter dbms_port to a string (e.g. '3306', 'localhost:3306', etc) rather than an int. Especially easy given that p4_port has to be a string. In release 0.5.1 it was especially unclear that this had to be an integer (config_bugzilla.py has it set to ????). config.py now has a sensible value here (i.e. 3306), but this requirement should be documented in the comment and in the AG, and tested in configure_bugzilla.py (see job000165). A. REFERENCES None. B. DOCUMENT HISTORY 2001-02-22 GDR Created using Perforce release notes as a model. 2001-02-23 GDR Updated for release 1.0.1. 2001-03-02 RB Added missing license. Transferred copyright to Perforce under their license. 2001-03-02 NB Updated for release 1.0.2. 2001-03-06 GDR Updated for release 1.0.3. 2001-03-19 RB Updated for release 1.0.4. 2001-03-21 NB Updated for release 1.0.5. 2001-03-25 RB Updated for release 1.0.6. --- This document is copyright (C) 2001 Perforce Software, Inc. All rights reserved. Redistribution and use of this document in any form, with or without modification, is permitted provided that redistributions of this document retain the above copyright notice, this condition and the following disclaimer. THIS DOCUMENT IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id: //info.ravenbrook.com/project/p4dti/release/1.0.6/release-notes.txt#1 $