<table style="width: 100%;" class="standard-table" border="1" cellpadding="2" cellspacing="0">

</tr>

</table>

<th>Task</th>

<th>Description</th>

<th>Assigned to</th>

<th>Status</th>

</tr>

<tr>

</td>

</tr>

<td>Retrieval of Change / Change set</td>

<td>The Granularity concept. A single revision may consist of hundreds or thousands of lines of code that were changed, yet only a couple lines of the change may be responsible for the regression. Thus, There must be a method to break the change into smaller manageable chunks. The different types of chunks we may breaking up a changeset are: Revision, Directories, Files, Code Blocks, and Lines.</td>

<td>[[User:RichardChu|Richard Chu]]</td>

<td>

<td>Application of Change / Change set</td>

<td>OK. Change sets can be retrieved. Now what? You must be able to apply a change or change set or subset of a change set to the source tree. Your mission is to figure out how to do that.</td>

<td>[[User:RichardChu|Richard Chu]]</td>

<td>

<td>Unapplication of Change / Change set</td>

<td>Changesets obviously must be able to be applied. But changesets must also be able to be unapplied. Your mission is to figure out how to do that.</td>

<td>[[User:RichardChu|Richard Chu]]</td>

<td bgcolor="#FFFF00">

<tr>

</td>

</tr>

<td>Wrapper around the GNU make utility</td>

<td>Mozilla uses the GNU make utility to build their source tree. your mission is to make a wrapper around the GNU make utility so that the make command can be programmatically called to build the source tree.</td>

<td>[[User:RichardChu|Richard Chu]]</td>

<td>

<tr>

</td>

</tr>

<td>Wrapper around the necessary SVN commands</td>

<td>For the automated debugging to work, we may need to automatically modify the working copy by reverting to a different revision or updating certain directories and files. It may also need to know the differences between revisions and changesets.</td>

<td>[[User:RichardChu|Richard Chu]]</td>

<td>

<td>Query SVN repository for differences between two revisions</td>

<td>Your mission is to find out the relevant commands that can return the differences between two revisions, the meta-data that is kept with each revision, how differences between two revisions are stored and formatted, and how this data can be parsed into a usable form for our project (wrapper?).</td>

<td>[[User:RichardChu|Richard Chu]]</td>

<td bgcolor="#00FF00">Done.</td>

<tr>

</td>

</tr>

<td>Wrapper around the necessary CVS commands</td>

<td>For the automated debugging to work, we may need to automatically modify the working copy by reverting to a different revision or updating certain directories and files. It may also need to know the differences between revisions and changesets.</td>

<td>[[User:dwwoodsi|Dean Woodside]]</td>

<td bgcolor="#FF0000">Just starting out.</td>

<td>Query CVS repository for differences between two revisions</td>

<td>Your mission is to find out the relevant commands that can return the differences between two revisions, the meta-data that is kept with each revision, how differences between two revisions are stored and formatted, and how this data can be parsed into a usable form for our project (wrapper?).</td>

<td>[[User:dwwoodsi|Dean Woodside]]</td>

<td bgcolor="#FF0000">Just starting out.</td>

<tr>

</tr>

<td>Creation / Extraction of Test Case(s)</td>

<td>We need test cases that can return whether or not the test passes or fails. Tinderbox has a couple of tests that are executed after the source is built. Extract those tests from the Tinderbox source code so that we can use them in this project. We also need a test case that can pass/fail consistently so that we can test the delta debugger.</td>

<td>[[User:Ankuswan|Aditya Nanda Kuswanto]]</td>

<td bgcolor="#FFFF00">Work in progress. Found the tests! Now need to figure out how to run them and how they work.</td>

<td>Test Framework</td>

<td>We ideally need a way to allow users to specify the test(s) to be run easily without them having to modify the delta debugging module. </td>

</tr>

<tr>

</td>

</tr>

<td>The Algorithm</td>

<td>The delta debugging algorithm. Drives the framework to retrieve change sets, apply changes, build source tree, run test case(s) to find the minimal set of failure inducing changes. The intersection of all other parts of the framework to make them work together. Ideally, should be abstract enough for easy extensibility with little impact.</td>

<td>[[User:RichardChu|Richard Chu]]</td>

<td bgcolor="#FFFF00">Work in progress.</td>

</tr>

</table>

== Points of Confusion ==