P4DTI Version 2 Revised Estimates

Contents

• 1. Introduction
• 2. Executive Summary
• 3. Requirements
• 4. Analysis
• A. References
• B. Document History

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:

• Bugzilla 2.18 support, including custom fields but excluding Sybase and PostgreSQL;
• Improved installation documentation;
• Configurable jobspec (Perforce job0008678);
• Improved recovery from replication errors.
• Fix miscellaneous bugs (job007829, job007870, job007871, job008038, job009794, job010283, job010285);

These requirements were identified as low priority:

• Improved Solaris support (patching, packages, testing);
• Perforce as a defect tracker (Perforce job008768);
• Remove filespec replication;

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.

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:

• Custom fields;
• Custom workflow;
• New groups system;
• Sybase and PostgreSQL compatibility;

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.

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

B. Document History

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.