Received: from swan.ravenbrook.com (IDENT:root@swan.ravenbrook.com [193.112.141.244])
	by raven.ravenbrook.com (8.9.3/8.9.3) with ESMTP id MAA01445;
	Fri, 24 Nov 2000 12:17:21 GMT
From: nb@ravenbrook.com
Received: from swan.ravenbrook.com (IDENT:nb@swan.ravenbrook.com [127.0.0.1])
	by swan.ravenbrook.com (8.9.3/8.9.3) with ESMTP id MAA24961;
	Fri, 24 Nov 2000 12:36:21 GMT
Message-Id: <200011241236.MAA24961@swan.ravenbrook.com>
To: nb@ravenbrook.com
cc: gdr@ravenbrook.com, p4dti-staff@ravenbrook.com
Subject: Defect tracker design discussion
Date: Fri, 24 Nov 2000 12:36:21 +0000

Defect tracker object should look up p4dti_bugs row at the same time
as the bugs row (in fact we could handle this in bugzilla.py)

Then the bugzilla_bug object should wrap the pair.  Call the
constructor from changed_issues or all_issues.  Pass None as the
p4dti_bug if there's no row.  Then in setup_for_replication() add the
p4dti_bug row if it's none.

The replicator calls changed_issues to get a list of issues (which are
members of the issue class).

For each issue, it calls the rid method to find out whether the issue
has been replicated before.  If the rid method returns the empty
string then the replicator calls the replicate_p method (currently
constant 1).  If replicate_p is 1, the replicator calls the
setup_for_replication method.  So the setup_for_replication method
gets called at most once.

Once an issue is set up for replication and is going to be replicated,
the replicator calls the action and jobname (now "human_name")
methods.  Then it looks up the actions in it's 'what to do' table ( dt
action, p4 action -> what to do ).  The 'what to do' table can say
"replicate this way", "replicate that way", "replicate normally", or
"conflicting; ignore".  If "replicate normally" and both have changed,
then there might be a conflict.  There's a conflict policy function to
decide whether there actually is a conflict and what to do.  If there
really is a conflict, then we mail the administrator and set the
actions to 'wait'.

Then the replicator uses the transform_from_job and transform_to_job
methods.  These are being replaced (so the defect tracker module
doesn't have to know about Perforce fields etc).  Instead we will have
translator classes (e.g. a class to translate dates between TeamTrack
and Perforce date formats), and a table of fields and translators in
the replicator config.  The replicator uses __getitem__ on the defect
tracker issue.  The replicator builds up a dictionary of changes
(field name -> new value) for each issue, then calls
issue.update(changes).  The replicator only calls __getitem__ on the
fields in the replicator config table, and never calls __setitem__.

After the replicator has tried to replicate an issue, it calls the
update_action method.

If the replication succeeded, it sets it to 'replicate'.

If replication from p4 to dt fails, we replicate from dt to p4 and
email the resolver and the person who made the mistake.  It sets the
action to 'replicate'.

If replication from dt to p4 fails, it sends email to the resolver and
sets the action to 'wait'.

update_action implicitly updates the database if necessary.

Transitions??

The replicator doesn't know anything about transitions.  When this
update function is passed some changes, it's up to update to figure
out what to do (e.g. in Teamtrack use transitions).  This is where I
should check permissions and raise an error if appropriate.