Ravenbrook / Projects / Perforce Defect Tracking Integration

Perforce Defect Tracking Integration Project

P4DTI Version 2 Revised Estimates

Nicholas Barnes, Ravenbrook Limited, 2003-02-13


1. Introduction

This document presents revised estimates for version 2 of the P4DTI, in response to a request from Gerry Thompson of Perforce Inc [Thompson 2003-01-21].

The intended readership of this document is Perforce and Ravenbrook P4DTI staff.

This document is not confidential.

2. Executive Summary

A previous document [NB 2002-12-17] analysed requirements for version 2 of the P4DTI, and presented estimates based on that analysis. Gerry Thompson of Perforce Inc responded to that analysis by e-mail [Thompson 2003-01-21] and requested revised estimates. This document presents revised estimates for the work items identified in that e-mail.

The total estimate for meeting those requirements is 715 hours of work. At the current P4DTI work rate of 52 hours per month, that is a little over one year's work. I continue to recommend an incremental delivery plan, delivering a new version approximately every two months. A version to support Bugzilla 2.18 should be planned for shortly after the Bugzilla 2.18 release.

It is not clear that the overall scope of these requirements is sufficient to justify incrementing the P4DTI major version number.

3. Requirements

The previous document [NB 2002-12-17, section 3] listed and analysed the requirements identified for P4DTI 2. This set of requirements has been modified in the light of that analysis. This section now lists the requirements currently identified for implementation in P4DTI 2.

Section 4 of this document analyses these requirements individually.

These requirements were identified as high priority:

These requirements were identified as low priority:

4. Analysis

This section briefly analyses and estimates each particular requirement. The estimation has been conducted by breaking down each change into analysis, design, implementation, documentation, and testing. This revised estimate does not present this breakdown, which is available on request.

All estimates are expressed as a number of hours of effort.

Requirement Total
Bugzilla 2.18 200
Improved installation documentation 30
Configurable jobspec 75
Improved error recovery 200
Miscellaneous bug fixes 30
Solaris support 50
Perforce as defect tracker 100
Remove filespec replication 30
Total 715

4.1. Bugzilla

As previously noted, Bugzilla 2.18 support is hard to estimate. In our experience, accommodating a single major Bugzilla change in Bugzilla takes 30-60 hours of work. The miscellaneous work of importing and supporting a new Bugzilla release amounts to about 70 hours.

The major changes planned for Bugzilla 2.18 are as follows:

For custom fields, we were originally asked to consider the cost of supporting Bugzilla's own custom fields patch. This request has now been dropped, so if custom fields does not make it into Bugzilla 2.18, the P4DTI will not support custom fields.

We have been told [Thompson 2003-01-21] that support for Sybase and PostgreSQL installations is not required.

4.2. Improved installation documentation

The installation documentation of the P4DTI is lengthy and may be confusing. We have been asked [Thompson 2003-01-21] to simplify it so that:

Documentation should state clearly that:
Bugzilla installation is the customer's responsibility.
Provide a clear matrix of supported prerequisite software versions.

4.3. Configurable jobspec

This corresponds to Peforce job008678.

The real question is, how easy does this have to be for the administrator? It is already possible, for a Python guru prepared to rewrite configure_bugzilla.py.

The cheapest way to meet this requirement is for the P4DTI to allow configuration of the jobspec and the "field map" (which defines how issue fields translate to job fields). These two items are currently generated by the P4DTI based on configuration parameters such as replicated_fields. Simplified versions of these two items could be exposed in the configuration file itself, for advanced administration.

4.4. Improved Recovery from Replication Errors

This is Perforce job 10280: marking jobs and issues which will not replicate as problematic, for handling in future polls. This will allow poll completion, and greatly reduce the difficulty of repeated poll failure. It seems likely that this must be achieved by storing this information in a flat file on the P4DTI server.

4.5. Fix miscellaneous bugs

The following Perforce jobs has been presented for inclusion in this estimate.

Job Description Notes
job007829 Improve replicate_p documentation. Need better non-TeamTrack documentation.
job007870 User migration should add replication user to Bugzilla. Not difficult, but time-consuming.
job007871 changing "sid" and "rid" breaks refresh. Changing the "sid" and "rid" parameters will not work. The P4DTI uses these parameters to identify records for replication in the defect tracker and in Perforce. The best we can do is to improve the documentation of the importance of this, and to fail with a more meaningful error message.
job008038 "Existing client". This needs some clarification. The description of it confuses a Perforce client name with a Perforce user name. It is certainly true that the P4DTI should avoid using an existing client for its access to Perforce, and I am taking that as the work description.
job009794 check_jobs.py fails under Windows with .py file association. Easy. Will need regression test.
job010283 Update documentation to reflect 'admin' access. Easy.
job010285 Remove references to deprecated software. Easy.

4.6. Improved Solaris support

This item has been scaled back to simply (a) testing on Solaris, (b) providing a Solaris package, and (c) documenting the dependency on GNU patch.

4.7. Perforce as a defect tracker

This means developing a "dt_p4.py" module to treat a Perforce server like a defect tracker (except without the ability to store fix records or changelist descriptions). The interesting questions here concern choosing jobs to replicate, and making different jobspecs interoperate.

4.8. Remove filespec replication

We have been asked to remove support for filespec replication from the code and the documentation.

A. References

[NB 2002-12-17] "P4DTI Version 2 Requirements Analysis"; Nick Barnes; Ravenbrook Limited; 2002-12-17.
[Thompson 2003-01-21] "Request for revised estimates for P4DTI version 2" (e-mail message); Gerry Thompson; Perforce, Inc; 2003-01-21.

B. Document History

2003-02-12 NB Converted to HTML and added to Perforce.

Copyright © 2002 Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.

$Id: //info.ravenbrook.com/project/p4dti/doc/2003-02-13/p4dti-2-requirements-analysis/index.html#4 $

Ravenbrook / Projects / Perforce Defect Tracking Integration