Mime-Version: 1.0
Message-Id: <p05001933b6a4861dab2e@[172.16.1.164]>
Date: Thu, 8 Feb 2001 02:03:36 +0000
To: p4dti-staff@ravenbrook.com
From: Gareth Rees <gdr@ravenbrook.com>
Subject: Test report for release 0.5.1, 2001-02-05
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Brad Barber installed P4DTI release 0.5.1 on Solaris 5.8.

Note that ATG are using Bugzilla 2.6, which is not supported by the 
integration.

Note that we were using Python 2.0, which is not supported by this 
release of the integration.

1. In the AG, section 4, the unpacking instructions for the Bugzilla 
integration should suggest changing to a suitable installation 
directory before unpacking the .tar.gz file.

2. In the AG, section 4, it suggests using "zcat".  But on Solaris 
5.8, the "zcat" command only works with Unix compress format.  I 
suggest using "gunzip -c" instead.

3. Brad claims that Solaris has its own packaging system and that we 
should deliver software packaged for Solaris.

4. The problem with HTML documentation is that shell users connected 
to the server by ssh or telnet will not be able to read it.  Yet 
another reason for having a copy online (see job000xxx).

5. If there were an index.html at the top level of the installed 
files which referred to the AG, UG, MG and IG, that would be useful 
to some people.

6. Brad didn't want to read the documentation.  He thought there was 
too much to read.  Eventually he gave up trying to read it and asked 
me to complete the installation for him.  What can we do about this?

Brad suggests a bulleted list of items, with detailed descriptions in 
a separate section.  He thinks that the software should alert users 
to missing prerequisites automatically.

The installation and configuration instructions could be separated 
into "things you must do first" and "things you can think about 
later".

7. More explanation may be needed in config_bugzilla.py (or perhaps 
less, forcing people to go to the AG).  For example, Brad thought at 
first that the sid parameter was the Perforce hostname?  He was also 
confused between Perforce client (in the sense of workspace) and 
Perforce client executable.  In that last case, giving 
"/usr/local/bin/p4" as the example might clarify things.

Our use of % to build parameters is confusing to people who don't 
know Python.  Concatenation with the + operator might be clearer.

Brad also suggests having more consistent documentation in 
config_bugzilla.py, perhaps an example with each parameter.

8. Enums in MySQL can have spaces in them.  But when they do, 
configure_bugzilla.py builds an incorrect Perforce jobspec.

9. A number of aspects of Bugzilla are different between 2.6 and 2.10, notably:

-- There's no "fielddefs" table (fields are just strings).
-- Some fields have different names ("bug_when" is just "when").
-- The permissions system works in a completely different way.

10. Brad has concerns about performance.  ATG already have 
performance problems with MySQL.  Will it be able to cope with 
locking and unlocking lots of tables every 10 seconds?

Brad suggests: 1. Instead of polling every 10 seconds, wait until a 
file changes, namely the Perforce journal file, and the MySQL log 
file.  On Unix you can arrange to wake up when a file changes.  2. 
Don't lock tables unless there's something to do: so read activity; 
if there is, lock the tables and re-read.  3. Change Bugzilla so that 
it writes a log for changes needing replication; then wait on that 
journal file.

This change would be necessary for Brad to consider relying on P4DTI. 
"There's no way we can deploy with a 10 second poll."

11. A bug in Perforce 2000.2: there's no tooltip for the JobStatus 
field in the change submission dialog.

12. Brad suggests that Ravenbrook should try making Bugzilla easier 
to install, by taking the source, making a new version and supporting 
it.  He doesn't suggest any source of revenue that might pay for 
this.  He suggests talking to Matt Rice about making a Linux 
installer for it.  He says that he would like to make his Bugzilla 
changes public; he would be happy to release these changes.

13. A bug in the Bugzilla patch: the instance of the variable $id in 
the EmitPerforceSection() function should be $bug_id (it happens to 
work because $id is a global variable but that's no reason to be 
sloppy).

14. The Perforce section in the bug form is too wordy.  Brad thinks 
that the information in this section is so important that it should 
be high up in the bug from.  But because space is limited on a web 
page the section should be as small as possible.  Brad thinks that 
the current design impairs usability and is thus unacceptable.