Mime-Version: 1.0
Message-Id: <p0433010cb64999cdf712@[193.112.141.252]>
Date: Tue, 28 Nov 2000 17:30:34 +0000
To: Perforce Defect Tracking Integration Project staff <p4dti-staff@ravenbrook.com>
From: Richard Brooksby <rb@ravenbrook.com>
Subject: Abolishing the role of resolver
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I was thinking about the writing the Administration section of the AG 
in order to resolve job job000081.  I asked GDR what circumstances 
could lead to the need for human intervention by the resolver. 
Currently there are two:

   1. an issue and its job are changed at the same time

   2. unable to replicate to Perforce

Case (1) should be rare, because issues generally belong to one 
person, and normally that person is the only one likely to make 
changes.  However, a manager might decide to reassign an issue at the 
same moment that a developer fixes the problem, or perhaps a tester 
adds some notes at the same moment that a developer writes a 
diagnosis.

Case (2) is almost always caused by a configuration error, so we 
should tell the administrator, not the resolver.

So we're going to require organizations to appoint someone, and 
provide quite a lot of documentation, just to deal with one quite 
rare situation.  Not only that, but the documentation is hard to 
write.  The whole thing is too complicated, in my opinion.

So I proposed today that we abolish the role of resolver.  When an 
issue and its job are changed at the same time we simply have the 
defect tracker win, and have the Perforce state overwritten, and send 
e-mail to everyone involved: the person who changed the issue in the 
defect tracker, the person who's change we overwrote (if we can work 
out who), and perhaps the owner of the job, if different.

In this way we abolish the whole idea of the resolver.  We can also 
simplify the code and remove all the support for conflicts ("keep", 
"discard", etc.).

We're moving towards treating the Perforce jobs as more of a slave of 
the defect tracker in general, and this allows us to simplify quite a 
few cases.  I think this is a valid thing to do, as very few people 
actually use jobs.  We can provide separate migration tools for them, 
if necessary.

For the beta, we should use the conflict resolution hook that GDR has 
implemented to implement a policy of "defect tracker wins".  If we 
get no complaints during the beta programme we should remove all the 
conflict handling code and replace it with this simpler model.