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 PAA02670 for ; Fri, 26 Jan 2001 15:05:29 GMT Mime-Version: 1.0 X-Sender: gdr@pop3 Message-Id: Date: Fri, 26 Jan 2001 06:26:02 -0700 To: p4dti-staff@ravenbrook.com From: Gareth Rees Subject: Test report for release 0.4.2, 2001-01-25 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Today Don Inghram (TeamShare's integration expert) was installing and testing release 0.4.2, with my help. 1. Don had some trouble using the readme.txt and the Administrator's Guide. He had a tendency to skip back and forth, missing important sections (for example, starting on section 5.2 of the AG before checking the prerequisites). I don't think there's much we can do about this: the AG is pretty clear. 2. Don had some trouble resulting from his lack of Perforce administration experience: for example, the Administrator's Guide tells you that you must have Perforce 2000.2 but doesn't say how to check the Perforce server version. I don't think this is serious: we do require that the integration admin has Perforce administration experience. 3. Don asked about Python licences. Maybe the AG could clarify that Python is open source and free of charge or licences? 4. The TeamTrack prerequisites section talks about requirements for workflow, like "can't have two states with the same name in the same project". Don asks, "what if you have two states with the same name in the same project, one 'deleted'? (TeamTrack doesn't actually delete states, merely mark them as deleted.) Does the replicator ignore the 'deleted' state?" Similarly, what about disabled transitions? We should check these cases. 5. We may need to give explicit instructions for running commands from DOS boxes (I think we already do this in the 1.0 manuals, but it did come up). 6. People stop and start the TeamTrack web server a lot (because their cache gets out of date). So the replicator needs to do something sensible. Moreover, people do switch from one TeamTrack database to another, so it's not necessarily sensible for the replicator just to wait and keep polling. 7. It would be useful to provide a link in e-mail to the URL for the TeamTrack issue. (How does one get the TeamTrack root URL from the API?) 8. Section 5.2 and config_teamtrack.py seems needlessly complex. Most of the configuration parameters have defaults that are perfectly fine, at least for initial testing purposes. So perhaps it should have two parts, (a) you must fill in these; (b) you might think about these later once you have it running. 9. If the replicator tries to send e-mail and fails (e.g., because the SMTP server is down), the e-mail is not stored anywhere, so the information is lost. (Note: TeamShare's SMTP server went down during my training session! The audience commented that it had been flaky all week...) 10. Don suggested that a good approach to the replication policy (replicate_p) would be to have an SQL query that selects the cases that should be replicated (e.g. TS_PROJECTID IN (10,12,15) AND TS_ISSUETYPE = 3 AND TS_STATUS IN (4,5,6)). Don says that many users are familiar with SQL because that's used in TeamTrack's reporting (and many users who are frustrated with TeamTrack's reporting learn SQL and write their own queries). Don thinks that projects will be most popular field to replicate on, issue types the second most popular. 11. The readme.txt provides a 1-user licence for TeamTrack. It doesn't point out that this is an expiring licence and that when you install it it will replace any existing expiring licence of the same type. This might annoy users who had a 10-user expiring licence and now find themselves with a 1-user expiring licence! 12. John McGinley points out that the TSServer::AddField() method will work the way the documentation says in release 45xx. That means that you must pass the actual table id you want to add the field to, not the FIELDS table. (See my e-mail exchange with Larry Fish from 2000-08/2000-09 for background to this.) 13. If a single-select field in TeamTrack is deleted, all records gets NULL for this field. But if the field is reinstated, the records keep the NULL values. However, NULL is an illegal value for a single-select field, and the replicator can't translate it, and so crashes when it tries to replicate. If the issue is updated in TeamTrack, the re-instated field gets the correct value (zero) and all is well. This is a bug in TeamTrack. 14. The TeamShare API doesn't cope with NULL integer fields. When you try to get the value for such a field by reading the intValue member, you get a random number. This is a bug in TeamTrack. 15. The manual needs to tell people that each time they change the configuration, they need to stop and start the replicator.