Received: from [10.1.2.49] (root@raven.ravenbrook.com [193.82.131.18])
	by raven.ravenbrook.com (8.9.3/8.9.3) with ESMTP id RAA17315
	for <p4dti-staff@ravenbrook.com>; Tue, 30 Jan 2001 17:00:35 GMT
Mime-Version: 1.0
X-Sender: gdr@pop3
Message-Id: <p05001917b69b62b57db8@[10.1.2.49]>
Date: Tue, 30 Jan 2001 09:00:07 -0800
To: p4dti-staff@ravenbrook.com
From: Gareth Rees <gdr@ravenbrook.com>
Subject: Test report for release 0.5.1
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Gerry Thompson and I installed release 0.5.1 on FreeBSD 3.0.  (Note 
that this is not a supported operating system for the P4DTI. 
Nonetheless we were able to get it to work, after a number of tricky 
problems.)

1. Line 16 of bugzilla.py says:

error = 'P4DTI TeamTrack interface error'

It should of course say "Bugzilla", not "TeamTrack".

2. When I started the replicator for the first time, I got this error:

Traceback (innermost last):
   File "replicator.py", line 1332, in run
     self.poll()
   File "replicator.py", line 823, in poll
     changed_issues, _, dt_marker = self.dt.changed_entities()
   File "dt_bugzilla.py", line 444, in changed_entities
     bugs = self.bugzilla.all_bugs_since(last)
   File "bugzilla.py", line 532, in all_bugs_since
     changed = self.fetch_rows_as_list_of_dictionaries(
   File "bugzilla.py", line 192, in sqlquote
     raise error, ("sqlquote given non-string %s." % str(value))
P4DTI TeamTrack interface error: sqlquote given non-string 2001-01-29 
18:23:27.00.

I looked at this in the debugger and it turns out that the offending 
value is the 'date' argument to 'all_bugs_since' which has this value:

<DateTime object for '2001-01-29 18:23:27.00' at 819a580>

Now take a look at this command and traceback:

>>>  dt.bugzilla.execute('select * from bugs')
2001-01-30 02:56:09 UTC P4DTI-00        replicator0     execute 
'select * from bugs'
Traceback (innermost last):
   File "<stdin>", line 1, in ?
   File "bugzilla.py", line 57, in execute
     rows = self.cursor.execute(sql)
   File "/usr/local/lib/python1.5/site-packages/MySQLdb.py", line 194, 
in execute
     return self._query(query)
   File "/usr/local/lib/python1.5/site-packages/MySQLdb.py", line 284, in _query
     self._rows = self._result and self._fetch_all_rows() or ()
   File "/usr/local/lib/python1.5/site-packages/MySQLdb.py", line 374, 
in _fetch_all_rows
     return _fetchall(self._result, self.arraysize, self._fetch_type)
   File "/usr/local/lib/python1.5/site-packages/MySQLdb.py", line 150, 
in _fetchall
     rows = r = list(apply(result.fetch_row, args))
   File "/usr/local/lib/python1.5/site-packages/DateTime/ISO.py", line 
102, in ParseDateTime
     return DateTime.DateTime(year,month,day,hour,minute,second)
mxDateTime.RangeError: month out of range (1-12)

It seems clear that the problem is in the DateTime module.  But why 
is the DateTime module being used at all?  DateTime isn't installed 
on swan.ravenbrook.com and the integration works fine there.

Well, it turns out that the MySQLdb module has one behaviour when 
DateTime is installed, and a different behaviour when DateTime is not 
installed.  Here's some code from MySQLdb.py illustrating this:

try:
     try: from mx import DateTime # new packaging
     except ImportError: import DateTime # old packaging
     from DateTime import Date, Time, Timestamp, ISO, \
          DateTimeType, DateTimeDeltaType
     [snip]
except ImportError:
     # no DateTime? We'll muddle through somehow.
     from time import strftime
     [etc]

So I made my own empty DateTime.py module in the same directory as 
the replicator (this overrides the installed DateTime module).  The 
replicator then worked fine.

3. Michael Biczinsky wants to know: will TeamShare be supporting the 
interim builds (4402, 4407 etc) in the event that 4.5 is not out in 
time?

4. In the documentation, we shouldn't use "the Integration" where we 
mean "the P4DTI".  "Integration" already has a meaning in Perforce 
and we don't want to confuse the issue even more than it is already.

5. In configure_bugzilla, the "Assigned_To" field is made "required" 
in the Perforce jobspec.  But what if a bug isn't assigned to anyone? 
(Bugs start out not being assigned to anyone.)  In that case we get 
an error from Perforce when we try to update the job:

p4 results: '[{'severity': 3, 'data': "Error in job 
specification.\012Missing required field 'Assigned_To'.\012", 'code': 
'error', 'generic': 4}]'

Probably the Assigned_To field should be optional, with no Preset. 
But note that the user_translator will need to deal with an empty 
Assigned_To field.

6. In problem number 5 above, you only get the error message above 
when you have verbose set to 1.  Otherwise, all you see is the 
following:

Perforce error: The Perforce client exited with error code 256.  Is 
the server down or the server address incorrect?

This is completely unhelpful.  So it looks to me as though the change 
to p4.py that made it take account of the exit code was too thorough: 
it allows a useless exit code to obscure a useful error message.  I 
suggest providing both the exit code and the error message (if any) 
in the Python exception.

7. To try to solve problem 5 above, I tried making the field 
'optional'.  But this didn't work because Perforce changed 'optional' 
to 'once'.  A little investigation showed that Perforce consistently 
changes the disposition of a field from 'optional' to 'once' when 
there's a Preset for that field.

8. MySQL 3.22.32 doesn't work with Bugzilla.  Users can't log in to 
Bugzilla.  The reason appears to be that the MySQL function 
encrypt($string) which is used to generate the encrypted password 
behaves differently from encrypt($string, substring($string, 0, 2)) 
which is used to check it.

I was able to work around this by changing encrypt($string) in 
globals.pl to encrypt($string, '\$1').

So is this another incompatibility between MySQL and Bugzilla?  Note 
that Gerry had installed a pre-built FreeBSD package of MySQL-3.22.32.