Mime-Version: 1.0
Message-Id: <p05001930b653cbd0fdb4@[193.237.68.82]>
Date: Wed, 6 Dec 2000 15:33:53 +0000
To: p4dti-staff@ravenbrook.com
From: Gareth Rees <gdr@ravenbrook.com>
Subject: Test report for release 0.4.0, 2000-12-06
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Today I was testing with P4D/NTX86/2000.2beta/18974.

I regression tested these closed jobs:

job000007 on 2000/12/06 by rb *closed* 'The fixes keyword can't be set '
job000013 on 2000/11/28 by gdr *closed* 'Deleting fixes not replicated'
job000026 on 2000/11/21 by gdr *closed* 'Fields may change even when rep'
job000035 on 2000/11/21 by gdr *closed* 'The replicator stops if an erro'
job000049 on 2000/11/30 by gdr *closed* 'Replicator fails when paths and'
job000053 on 2000/11/30 by gdr *closed* 'Implicit changes made by the DT'
job000057 on 2000/11/30 by gdr *closed* 'Special characters in single-se'
job000063 on 2000/11/30 by gdr *closed* 'Dates aren't replicated with fi'
job000102 on 2000/11/30 by gdr *closed* 'The resolver exists but shouldn'
job000107 on 2000/11/30 by gdr *closed* 'You can't replicate an issue's '

1. The replicator tries to e-mail (None) when a job has no owner, and 
this fails because (None)@ravenbrook.com is not a valid e-mail 
address -- (None) is a comment in RFC822 so there's no address-part. 
This is because Perforce will happily make up an e-mail address for a 
non-existent user when you run "p4 user -o (None)".

2. The replicator gets into trouble if it fails to replicate from the 
defect tracker to Perforce.  It doesn't mark the changes as having 
been dealt with, so the next time it polls it encounters the same 
problem and sends the same e-mail, and still gets no further.  So the 
administrator gets an e-mail every 10 seconds and the replicator 
makes no progress.

3. There's no help text for the JobStatus field in the change 
specification dialog in P4Win.  (All the other fields have help text.)

4. The JobStatus field comes up blank in the change specification 
dialog in P4Win, regardless of what you set it to.  But it does get 
used when you submit.

5. We found that we couldn't close a job by fixing it, but we could 
close a job by setting the status to closed.  TeamTrack refused to 
replicate the change to the job (but wouldn't say why).

6. In the MS Developer Studio plugin, you get a JobStatus field when 
you submit, but it's not a drop-down field, just an empty text field.

7. When the user who last edited a job is the same as the owner, 
their e-mail appears twice in the To: field of any messages sent by 
the replicator about that job.

8. The message you get when a transition is not found is cryptic (it 
uses the state IDs, not their names).

9. The UG needs a table of contents.

10. Is "Finding changelists that aren't associated with an issue" a 
use case that should go into the UG?  (Of course such a section ought 
to include specializations like "Finding changelists on a release 
branch that aren't associate with an issue of such-and-such a 
priority or higher.")

In Unix this command is a start:

    p4 changes ... | cut -d ' ' -f 2 | (while read CHANGE; do if [ 
"`p4 fixes -c $CHANGE`" == "" ]; then p4 describe -s $CHANGE; fi; 
done)

but one would like to have better reporting than that gives you.  And 
what about Windows?

11. A user can add a fix to a job even if they don't have permission 
to update or transition the corresponding issue.  Although the job 
gets reverted, the fix stays.