Received: from [10.1.2.220] (root@raven.ravenbrook.com [193.82.131.18]) by raven.ravenbrook.com (8.9.3/8.9.3) with ESMTP id AAA21623 for ; Wed, 25 Oct 2000 00:23:34 +0100 (BST) Mime-Version: 1.0 X-Sender: rb@pop3-ravenbrook Message-Id: Date: Tue, 24 Oct 2000 17:22:58 -0600 To: Perforce Defect Tracking Integration Project staff From: Richard Brooksby Subject: TeamShare PSG Alpha Test Report, 2000-10-24 Content-Type: text/plain; charset="us-ascii" ; format="flowed" 1. INTRODUCTION These issues were noted during alpha testing of P4DTI 0.3.2 with Derek George of TeamShare PSG on 2000-10-24 between 11:00 MDT and 16:30 MDT. 2. PERFORCE CHANGES The following changelists were submitted from TeamShare in order to resolve some of these issues. p4 changes "version/0.3/...@2000/10/23,2000/10/25" Change 3695 on 2000/10/24 by gdr@gdr-derekpc 'Fixed bug discovered during alp' Change 3694 on 2000/10/24 by gdr@gdr-derekpc 'Fixed problems discovered durin' 3. ISSUES 1. When the replicator can't find a legal transition is uses "update" to change the state, and succeeds. It shouldn't succeed, as this means that Perforce users can override the workflow. Update should never be used to change the state. Derek says it shouldn't be used to change any of the "system information". 2. P4WIN shows the first N fields (by what ordering?) in the job edit dialog. We should push non-editable P4DTI internal fields down to the bottom. 3. If there's a transition from state A to state A and the user changes something in Perforce, should we apply the transition? This is a special case of the "two transitions from A to B" problematic workflow, and we need to point it out to people in the manual. 4. Same problem as (1) but with ownership of cases. 5. We need to go through your implementation looking for assertion statements and making sure they are really "impossible" and not run-time error conditions. The latter should run recovery code and possibly send an exception message to the administrator/resolver. 6. You should always step through every line of code you write. It finds many defects early. You need to learn how to use the Python debugger to do this. It's also necessary for debugging in the field. 7. The TeamShare API is case insensitive but Python is not. This means that some dictionary lookups fail, for example looking for the state. Suggest altering the code to either make lookups insensitive or transform all strings to upper case as the come in. 8. Following on from (7), are job fields case sensitive as well? 9. Two ways of resolving conflicts: either set to "discard" or fix up the problem and set to "keep". Need to document both of these. 10. Can we stop everyone from being able to set the action to "keep" or whatever? 11. Some exceptions will be caused by simple mistakes, such as forgetting to enter a required field. Can we avoid involving the resolver in those? Just send a message to the user? Perhaps Cc the resolver and send another message when the problem is resolved by the original user. 12. There's no GUI interface to Perforce fixes. 13. Can't require Notes to be filled in from the Perforce end, because they're TeamTrack attachments, not in the CASES table, and not available for replication. 14. Need frame borders on the Fixes table in the TeamTrack UI, as I proposed. 15. The replicator doesn't copy the status field values from the jobspec yet, so one can't edit fixes from the TeamTrack UI. 16. We haven't thought through what it means to edit the "effect" of a fix retrospectively from the TeamTrack UI. 17. Assertion error when editing a fix in TeamTrack. 18. We need a convention for cross-referencing comments in code. 19. Need stronger conventions about development coding practice, especially in version branches. Don't delete stuff. Add comments explaining why a change was made (especially in version branches). Sign comments. Refer to reports of defects when fixing them. Check in each defect fix separately. What to put in change comments, and so on. The goal being to make it possible to decide about merging into the masters later, and for different people to maintain the code along the version branch successfully. 20. Replicating the jobspec is the wrong thing to do (for status-values). Use the statuses that actually map to something. 21. TeamTrack looks like it doesn't actually read the STATUS_VALUES replicator configuration. 22. If a fix is not up to date in the VCACTIONS table and the job is in conflict with the issue, then it never gets up to date until the conflict is resolved, and so you'll get an e-mail every ten seconds about it! 23. The replicator isn't updating the replicated time of fixes when it replicates them. I think that we're essentially not ready for editing and creating fixes on the TeamTrack side. Should we really be letting people edit and update fixes on the TeamTrack side? 24. When it decides not to replicate we should report the fact. 25. Workflows are different for different issue types, so different transitions are available for different issue types. But the ReadTransitionList function only takes a projectid as its parameter. So the replicator can't accurately tell which transitions are valid for the case. API change needed? Document as a limitation. 26. What about when a case was replicated by accident (perhaps when it was entered in the wrong project to start with). 27. When you open a job in Perforce, it comes up with status "open" even though it's really in status "new". This is because "new" is special in Perforce. 28. In Perforce job edit dialog, some fields (namely select fields) don't have a colon after the field name. That seems a bit inconsistent to me. (Bug in Perforce.) 29. You can fix pending changelists from the GUI, but only to "Closed". (Bug in Perforce.) 30. Can you use an "always" field in the jobspec to make edited jobs change to "keep" action when you edit it? 31. Can we provide a TeamTrack interface to the P4DTI_ACTION field by putting the right data in the FIELDS and SELECTIONS tables? We need to investigate.