Mime-Version: 1.0
Message-Id: <p05001911b65697a3c160@[193.112.141.254]>
Date: Fri, 8 Dec 2000 16:13:23 +0000
To: p4dti-staff@ravenbrook.com
From: Gareth Rees <gdr@ravenbrook.com>
Subject: Test report for release 0.4.2, 2000-12-08
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

1. The Microsoft Visual C++ project settings are wrong in the Win32 
Release configuration: the build target should be 
..\release\teamtrack.dll, not Release\teamtrack.pyd.

2. The release-build procedure is not explicit about how to check the 
project configurations in MSVC++.

3. The release-build procedure is not word-wrapped.

4. Typo in AG, 2.2: "Perforce user can" -> "Perforce users can".

5. AG, 3: overstates the administrator entry requirements, in RB's opinion.

6. AG, cross-references could do with tidying up as per LMB's 
suggestion.  Some of them aren't very specific.

7. AG, section 3.2: doesn't tell you how to check your workflow.  In 
fact, the replicator can check all of these problems (and does check 
the first).  It should check them all; then we could tell the admin 
to see what turns up and suggest fixes in 13.2.

8. AG, section 5: the warning about proceeding with an incomplete 
configuration is not strong enough.

9. AG, section 5.2: in the teamtrack_password bit there needs to be a 
forward reference to 5.3.

10. config_teamtrack.py refers to section E of the AG but in fact 
section D is needed.

11. AG, 5.3.1: claims that you have chosen a p4_user when in fact the 
admin might not have

12. In config_teamtrack.py there is a very poor default for replicator_address.

13. Using company.com is a bad idea, because it exists.

14. AG, 7: may need to tell people how to run a command interpreter.

15. AG, 13.2: "Perforce error: You don't have permission for this 
operation" may mean that you have Perforce protections wrong. 
Similarly "TeamShare API Error: SERVER_ERROR: Authentication Failed. 
Invalid user id or password" means that you

16. It may have been a bad idea to remove the Polling... message; you 
can't tell what it's up to.  A good solution would be to say 
"Waiting..." once after each burst of activity.

17. We need to document the fact that the replicator doesn't actually 
do anything when it starts!

18. When started with some logger output left over from the last time 
we were replicating to that Perforce server, the replicator 
replicated lots of changelists on starting, and because the users 
didn't exist in TT, it kept re-reading the USERS table.  Not only 
that, but it tried replicating the same changelist many times, 
reading the USERS table each time.  This looked like it had crashed 
or gone berserk, when in fact it was working.  So two problems here: 
(1) not uniquifying the list of changelists in the logger output and 
(2) re-reading the USERS table too many times.

19. The consistency checker reports consistency failures 
(unreplicated issues) even if the replicator is working perfectly. 
This is because the replicator doesn't replicate historical issues.

20. UG, 5.1: talks about Owner and State fields in the jobspec 
whereas the Bugzilla integration uses User and Status.  This is not 
quite right.

21. UG, 6.1 step 1: delete "whose status".

22. UG, 6.1: the menu item is not "Edit Job XXX" but "Edit Spec XXX".