Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.249]) by raven.ravenbrook.com (8.9.3/8.9.3) with ESMTP id RAA13363 for ; Thu, 14 Dec 2000 17:07:55 GMT Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) by thrush.ravenbrook.com (8.9.3/8.9.3) with ESMTP id RAA57441 for ; Thu, 14 Dec 2000 17:05:39 GMT From: Nick Barnes To: p4dti-staff@ravenbrook.com Subject: Test report for release 0.5.0, 2000-12-14 Date: Thu, 14 Dec 2000 17:05:39 +0000 Message-ID: <57439.976813539@thrush.ravenbrook.com> Sender: nb@ravenbrook.com I had a good experience with this release. I have got a replicator running without too much trouble, and it works. Biggest gripes: 1.6, 2.17, 2.18, 7, 8(?) 9(?). If these get fixed then I think it's usable. I also think we will have to get long descriptions replicating before release 1.0. 1. In readme.txt: 1.1. release 0.5.0 does not support TeamTrack, but the readme.txt states otherwise. 1.2. The releases index page doesn't mention "defect reports". 1.3. The releases index table has 0.4 as the origin for 0.5.0. 1.4. job000068 is not really a product defect. 1.5. is job000137 a duplicate of job000086? 1.6. "Installing the Bugzilla Integration" doesn't say that one should go on to read the AG after untarring the tarball. This seems important to me. 2. In the AG: 2.7. section 2.2: "perforce user can" 2.8. section 2.2: "—" doesn't work in my browser. 2.9. section 3.1: "If you're using the TeamTrack integration, you should check that your users have the same e-mail address or the same userid in TeamTrack as in Perforce. See Section 3.2." This applies to Bugzilla as well. 2.10. section 4: "a copy of P4DTI product release version 0.5". This needs rewording. 2.11. section 5.2: these items are in a different order in the AG to the config file, which is slightly confusing. 2.12. section 5.2 should refer to section 5.5.2 2.13. section 7.1 says I should "python run_teamtrack.py" 2.14. section 7.2 ditto check_teamtrack.py 2.15. section 5.3 should say that you should delete all existing Perforce jobs. This is mentioned in earlier text, but this is the point at which you actually do it. 2.16. section 7 in general needs a lot of work. 2.17. The AG doesn't clearly tell me how to actually run the P4DTI. 2.18. The whole bugzilla_user/p4_user thing (sections 5.2, 5.3, 5.5) needs clearing up. I understood it but I don't think a third party would. 3. The files in the release are all in one directory; there's no separation between code and manuals. This is unconventional in the Unix world (which means that Unix users might well find it irritating or confusing; I know that I do). 4. The tar file untars into a directory called p4dti. It's conventional to untar into a directory called - (e.g. p4dti-0.5.0 or p4dti-bugzilla-0.5.0). 5. example_trigger.py appears to refer to itself as p4dti-enforce-job.py. 6. in the UG: 6.1. section 3 says "Section not written yet", but it is. 6.2. 7. The replicator output is much too verbose. All that SQL, ick. Should add a verbosity flag to bugzilla.bugzilla. 8. The fact that "closed" doesn't match RESOLVED is irritating, and IMO will cause complaint. 9. It seems on first inspection that illegal transitions don't replicate to Bugzilla (good) but that fact doesn't appear in the log. I don't understand this, and it needs further investigation. -- FreeBSD 4.1-RELEASE: up 28 days, 2:04 last reboot Thu Nov 16 15:01 (new machine)