Changes between Version 1 and Version 2 of Summer Of Code

Timestamp:

Jun 14, 2005, 7:57:22 PM (19 years ago)

Author:

cmlenz

Comment:

Minor corrections

Summer Of Code

@@ -3 +3 @@
 Today's automated builds generate a tremendous volume of information about the state of software development projects. This starts with basic status indicators such as compilation errors and test failures, but is increasingly extended to include advanced software metrics such as dependency analysis, code coverage analysis or style checking.
 
-Traditionally, continuous integration systems such as Tinderbox. BuildBot or Gump only record and display the data that the build system prints to the standard output and error streams. Thus all the information about a code base generated by the build often cannot be used to full extent. 
+Traditionally, continuous integration systems such as Tinderbox, BuildBot, or Gump only record and display the data that the build system prints to the standard output and error streams. Thus all the information about a code base generated by the build often cannot be used to full extent. 
 
 To effectively provide value for the ongoing development and management of a project, data generated by builds needs to be collected in a central repository, and in a machine-readable format, to allow for analysis and presentation of the data even long after the actual build has been run. In addition to being able to adjust how data is analyzed and presented in retrospect, this approach is essential for historical reports that show how specific metrics are evolving over time -- which is often more valuable than the absolute values of these metrics at one specific point in time.
@@ -9 +9 @@
 == Main objectives ==
 
-The goal of this work is to design and implementat of a distributed system for automated builds and continuous integration that allows the central collection and storage of software metrics generated during the build. The information collected this way needs to be structured and available in a machine-readable format, so that it can be analyzed, aggregated/correlated and presented after the build itself has completed.
+The goal of this work is to design and implementation of a distributed system for automated builds and continuous integration that allows the central collection and storage of software metrics generated during the build. The information collected this way needs to be structured and available in a machine-readable format, so that it can be analyzed, aggregated/correlated and presented after the build itself has completed.
 
 The system is required to meet the constraint of neutrality towards programming languages and tool chains: at its core, it must not assume that any particular language or build tool is in use by a project. Rather, it should provide a generic framework for the execution of builds, and collection of data from builds, and for persisting this information in a central location to make it available for various kinds of reports. The system needs be extensible to support various specific languages and tool-chains in a meaningful manner. 
@@ -19 +19 @@
 The design of the system will be based on distributed CI systems such as Tinderbox and BuildBot: a central build orchestrator (or build master) is responsible for the coordination of several build slaves that do the actual work of executing builds. The orchestrator is a daemon that knows what to build and how to build it; it provides this knowledge as a build recipe to the build slaves, which report their status and results back to the orchestrator after the build - or parts of the build - have completed.
 
-The system will be composed of three layers: the build slave, the build master and the Trac plugin. There are three core aspects that all three  layers deal with: the build itself, the generated data and the status of the build. The main emphasis of this work will be on the second of these aspects: the conversion,  collection and presentation of the data generated by builds.
+The system will be composed of three layers: the build slave, the build master, and the Trac plugin. There are three core aspects that all three  layers deal with: the build itself, the generated data, and the status of the build. The main emphasis of this work will be on the second of these aspects: the conversion,  collection, and presentation of the data generated by builds.
 
  Data conversion:: There is a large variety of different tools that generate data in different formats, including the build system itself, as well as any additional tools integrated with the build, such as unit testing frameworks, code coverage analyzers or style checkers. The data produced by these tools needs to parsed and converted so that it can be handled appropriately. This conversion is done by both the build slave (mainly to prepare the data for transmission to the master) and by the build master (to convert the data into a format suitable for storage and analysis.) 
@@ -27 +27 @@
  Data presentation:: Presentation of the collected data is handled by a Trac plugin. This plugin has access to the database maintained by the build master and provides means to visualize the data or make it otherwise accessible through the web interface. Trac itself will be extended to expose additional extension points where necessary, for example to integrate software metrics and stastistics in various places, such as the timeline and the repository browser.
 
-The focus of tool support will be on Java and Python projects and the predominant build systems used with those languages. For Python projects, the standard modules unittest and trace.py can be used for unit tests and code coverage, and third-party scripts such as pychecker and PyLint may be used for style checking and other metrics. For Java projects, the integration of tools such as JUnit, Clover/jcoverage and JMetric will be examined.
+The focus of tool support will be on Java and Python projects and the predominant build systems used with those languages. For Python projects, the standard modules unittest and trace.py can be used for unit tests and code coverage, and third-party scripts such as pychecker and PyLint may be used for style checking and other metrics. For Java projects, the integration of tools such as JUnit, Clover/jcoverage, and JMetric will be examined.
 
 == Implementation notes ==