Received: from [10.128.16.193] (root@raven.ravenbrook.com [193.82.131.18]) by raven.ravenbrook.com (8.9.3/8.9.3) with ESMTP id BAA09039 for ; Thu, 2 Nov 2000 01:55:20 GMT Mime-Version: 1.0 X-Sender: gdr@pop3 Message-Id: Date: Wed, 1 Nov 2000 17:54:11 -0800 To: p4dti-staff@ravenbrook.com From: Gareth Rees Subject: Alpha test report for Quokka Sports, 2000-11-01 Content-Type: text/plain; charset="us-ascii" ; format="flowed" This is a report on issues that came up during alpha testing at Quokka Sports on 2000-11-01. 1. Rob asks: could there be a web page that lists all the outstanding problems in the database? (This could be something that runs the consistency checker and has a "refresh button" at the top.) This could be a TeamTrack report (since the P4DTI_ACTION contains the information you need), or a Perforce query like "p4 jobs -e P4DTI-action=wait". 2. Could there be control over checkout? Could an organization prevent someone from checking out a file unless there's a job associated with it (at least on some branches anyway). Note that some people have asked for a similar requirement on submit. 3. It would be really nice to be able to make a fix with the default changelist. 4. Advice for people designing the association between TeamTrack and Perforce: don't have too many required fields for the developer to fill in. 5. Perforce's web site needs to say which release of the integration supports which TeamTrack release. 6. What happens when the replicator crashes? How will it be brought up again? Need documentation about this. 7. What happens if you back out a change? Will the replicator cope? There needs to be documentation explaining what to do wrt the integration when backing out a change. Should the Perforce manuals that explain the procedure refer to our documentation. 8. Our naming convention for modules and classes is poor. [Something to do with the file names being the same as the things they contain, which is a pain.] 9. At startup there should be some progress report. When there are 10,000 bugs it can take a long time. 10. If there's an error when replicating for the first time, the replicator believes that there's a corresponding job, then fails when it tried to replicate, because there's no job. Possibly the "setup_for_replication" method shouldn't set the corresponding job until we know that it's been created. 11. If you set the "Job" field in the jobspec to "once" and a Preset is made, then a job is create job, the job name shows up as the preset in some places, but inconsistently as the command-line job name in others. For example, "p4 jobs" shows a different name to "p4 job". 12. The integration code has the "Status" field name hard-coded. We changed it to "State" and it didn't work. 13. We failed because a "single-select" field was a "text" field in the jobspec. The consistency check should include checking of the jobspec field types and presets against the integration configuration and what the DT expects. 14. We failed because the "priority" field at Quokka is defined with a mixed case name in the database, unlike the default TeamTrack name which is upper case. The consistency check should check all the field names in the configuration match those in the TS_FIELDS table. We fell over mixed case field names. Perhaps the replicator should normalize all cases of everything anyway. The documentation needs to warn people about the cases if not, and tell people to use the names from the TS_FIELDS table. 15. Quokka staff member MacKenzie S. reports that he'd rather be slapped with a wet fish, failing requirement 75's critical minimum level. [Surname elided at request of Quokka Sports. RB 2000-11-08] 16. We didn't bring a wet fish to slap people with.