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 <http://www.perforce.com/perforce/products/p4dti.html>.
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 <http://www.perforce.com/perforce/products/p4dti.html>
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 <support@perforce.com> or see the
technical support page at
<http://www.perforce.com/perforce/support.html> for contact information.
For problems relating to TeamShare, contact TeamShare Technical Support
by writing to <support@teamshare.com> or see the support page at
<http://www.teamshare.com/support/index.htm> for contact information.
Bugzilla is not supported by any one person or organization. Consult
the documentation that came with Bugzilla, or visit
<http://bugzilla.mozilla.org/>.
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
<p4dti-discussion-request@ravenbrook.com> 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
<http://info.ravenbrook.com/project/p4dti/branch/2000-12-18/manual-prep/manual/ag/#section-10>
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 <URL:
http://www.lemburg.com/files/python/mxDateTime.html> 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
<URL: mailto:andy@dustman.net>.
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 $