DEFECT TRACKING PROJECT MEETING, 2000-05-11 Gareth Rees, Ravenbrook Limited, 2000-05-11 1. INTRODUCTION This document records a meeting between Christopher Seiwald, Nigel Chanter, Leslie Smith and Laura Winger of Perforce Software and Richard Brooksby and Gareth Rees of Ravenbrook Limited. The goals of the meeting [RB 2000-05-08] were to review project goals; to present project progress; to present the requirements [RB 2000-05-05]; to present architecture proposals [GDR 2000-05-08]; to get feedback on the project and approval of the results; to get agreement on how to proceed with the project; to get agreement on Ravenbrook's involvement in the next stage; and to agree how to make decisions about architecture, which companies to work with, how open to make the project, and project resources. The intended readership is anyone involved in the project. This document is intended for Perforce Engineering Management, but could be made available to all staff. It is Perforce Software client confidential. 2. ARCHITECTURES 2.1 Manual architecture This should not be considered. 2.2 Tracker-client architecture This should not be the only solution, but it is a way of making a "quick fix" that allows Perforce to make a marketing claim of integration. We could improve the documentation of the existing API, but the existing API is really for a different purpose. It may be more appropriate to wrap the API in a special-purpose tracker-client API. We want to make it easy for the defect tracker to keep data consistent with Perforce. Perforce needs to use its relationships with defect tracking vendors and goodwill on the vendor sides to make this work. There will be consistency problems with this architecture. The rest of the solution will address these problems. 2.3 The single-database architecture. If jobs and fixes are stored in the defect tracker's database, there is an integrity issue: if you back up Perforce's repository, you don't back up all its data. There is potential for huge slowdown in Perforce's response to transactions invoving jobs (remember that this includes all submissions). Perforce must lock everything to do with the transaction and this may lead to deadlock. Defect tracking vendors must change the way they work with the databse so that they have two-phase commit (otherwise the jobs data will become inconsistent with the rest of Perforce's data). This probably requires more programming skill than they have. Perforce could work around this by adding the ability to back out a change to its database if something went wrong, and/or by writing a tool to keep things in sync. But this ends up looking a lot like the replication architecture. 2.4 Replication architecture Perforce could provide a flag on information in its repository indicating the (possible) presence of an inconsistency in the defect tracker's database. This could be used to prevent people from operating further on inconsistent data. 2.5 A new architecture (This is a new variant on the union architecture.) Put all the defect tracker's data in the Perforce database. This may be possible when you have access to the defect tracker's source code (for example, Bugzilla or GNATS). Or you could present an ODBC interface from Perfroce to the defect tracker. ODBC is likely to be too general -- but you could work out what the defect tracker is up to and turn it into the appropriate Perforce query. This probably requires co-operation from the defect tracker -- we would need to know all the queries they make. The implementation would be fragile -- if the defect tracker added new queries the integration would break. The main reason why this will fail is that customers are using the database for more than just defect tracking -- they may have all their enterprise data in the same Oracle database with the defect tracker's data so that they can make joint queries. They will not be able to move all this data into Perforce. 3. VENDORS 3.1 TeamShare and TechExcel Are keen to intergrate and willing to put in effort. Good choices. 3.2 Remedy They have a "partner program". They are worth following up in more detail because they have a very flexible and high-level system and they will have a broder view of requirments than we have had so far. Note that they support organizations who change their process every week! (But these organizations are prepared to do this configuration work and so will be happy to do it to integrate with Perforce.) 3.3 Bugzilla Not really a defect tracker. 3.4 Rational An important system -- several Perforce customers have requested integration. We may be able to build an integration using only their published APIs so may not need to deal with them directly. Worth investigating further. 3.5 StarTeam They are partner happy -- even though they already have their own software configuration sytstem they advertise integration with PVCS. Might be persuadable to do the same for us. 3.6 PVCS Tracker As for StarTeam [3.5]. 3.7 Summary It is worth investigating the big-company vendors (Rational, Remedy) to make sure that our requirments are general enough. It is worth targeting popular systems like PVCS Tracker, StarBase and Rational because defect tracking selection and purchasing often precedes configuration management selection and we don't want to prevent people picking Perforce just because it doesn't integrate with their defect tracking system. 3.8 Priority of effort -- Replication -- Single-database -- Union. 4. PLAN The project continues as planned. 5. ACTIONS Perforce need to start recording reasons for customer purchasing decisions. This will allow the sucess of a project like the defect tracking integration to be measured (in terms of the customers who cited the integration as a positive factor in their purchasing decision). We need to talk to customers who rejected Perforce because of its lack of defect tracking integration. Leslie will provide a list of these customers. We need to review the requirements document with the users who are its sources. We have approval from Christopher Seiwald to do this (even including the list of vendors we are thinking of integrating with). We must deliver soon our proposed changes to the Perforce database. This is important for architecture selection, to enable Christopher to plan his work, and to minimize painful upgrades for Perforce customers. We should make the project open -- this will give us early feedback, goodwill and credibility (Perforce can point to the project when asked about defect tracking integration). We need to avoid giving too strong impressions of commitment to deadlines to avoid disappointment and loss of credibility. A web site for the project would be a ood idea -- it could be linked from Perforce's main site, have copies of all the reports, and so on. We need to know constraints on Perforce's resources. (Money is plentiful but human resources are scarce.) A. REFERENCES [RB 2000-05-05] "Requirements for defect tracking integration"; Richard Brooksby; Ravenbrook Limited; 2000-05-05. [RB 2000-05-08] "Defect Tracking Intergration project meeting" (e-mail message); Richard Brooksby; Ravenbrook Limited; 2000-05-08T18:19:34Z. [GDR 2000-05-01] "Requirements and use cases for Perforce/defect tracking integration"; Gareth Rees; Ravenbrook Limited; 2000-05-01. [GDR 2000-05-08] "Architecture Proposals for Defect Tracking Integration"; Gareth Rees; Ravenbrook Limited; 2000-05-08. B. DOCUMENT HISTORY 2000-05-11 GDR Written based on notes taken during the meeting. $Id: //info.ravenbrook.com/project/p4dti/doc/2000-05-11/project-meeting/index.txt#1 $