1
edit
Changes
→Project Details
'''Facts and Assumptions:'''
# The source tree for the Mozilla project is HUGE. With many different source file types (C++, JS, XUL, etc.) in many different directories.
# Failure-inducing change(s) will unlikely be localized to a single directory and file. Failure-inducing change(s) may be spread across many different directories and source files.
# The source files could be of the same type (C++), mixed type (C++, JS), same directory, different directory. It shouldn't matter. The framework should be source type and location agnostic.
# The developer's current version of the source code contains the regression.
# The developer has a test case that can be used indicate whether the test passes/fails/is indeterminate.
# The developer knows will NOT know the last known good date/version number or of the date of last known good version. The latter will most likely be simpler and more user friendly.
# Bonsai is a tool that can produce a list of differences between versions of a source file. (Bonsai's functionality has not been examined closely yet but will have to as it may be a key component to the framework)
# Since the last time a developer executed a test case that passed, the developer modified some source files. The source files may be of the same type or mixed type, same directory or different directory. It shouldn't matter. The framework should be source type and location agnostic. Upon executing the test case again, the result is now a failure. The developer panics. It's only days before the deadline to submit bug patches before the source tree is supposed to be closed for release and the bug is a blocker. The developer doesn't want to be shamed for delaying the release, and the source code is too complex to find the bug in time, so what should they do? Use the delta debugging framework! that's what. How? you may ask. Well keep reading to find out. <small>* scenario may vary.</small>
# The delta debugging framework may require the developer to input two pieces one piece of information. One, the The test case/function that used to pass but now fails. It will be used to determine whether the source files with progressive changes passes/fails the test. Two, the date of the last known good version that passed the test case. Because of assumption 4 made above, the source directory and files or name of the developer may not be required.# Once the developer has inputted the two pieced this piece of information, it will use Bonsai to query the source tree and compile a list of all of the changes to the source files since the inputted date. Another possible step to take is to download the source code from the inputted date, compile the source tree and execute the test case to determine whether or not the version on the inputted date actually passes the test case. Why? Because of the age-old idioms a certain amount of (1) users are stupid and (2) never trust user input. Of course, if this is done, then step 5.1 would change slightly from removing changes to applying changestime.
# (If there was a method of determining change dependencies so as to eliminate the possibility of inconsistencies, it would be done in this step. One possible way of reducing the possibility of inconsistencies is to logically group changes by location or check in time.)
# This step would be where the delta debugging algorithm would come into play. The algorithm should basically:
The flowchart represents the simplistic version of the delta debugging algorithm. It will theoretically find a failure-inducing change set but not necessarily the minimal set or the full set of failure-inducing change(s). The algorithm is depicted as recursively linear however it could be binarily recursive. In the linear version, the theoretical maximum number of iterations (worst case scenario) is:
[[Image:Dd_maxiterations.PNG]]
where ''n'' represents the total number of changes and ''r'' is a subset of ''n''.
In other words, the summation of the combinations of changes without repetitions that can be made given that the size of the change set can vary from 1 to ''n''.
[[Image:Dd_flowchart.PNG]]
'''Task List'''
<table style="width: 100%;" class="standard-table" border="1" cellpadding="1" cellspacing="1">
<tr>
<th>Task</th>
<th>Description</th>
<th>Assigned to</th>
<th>Completion date goal:</th>
<th>Status</th>
</tr>
<tr>
<td colspan="5"><strong>Mozilla Bonsai</strong> ([http://www.mozilla.org/bonsai.html http://www.mozilla.org/bonsai.html]) <br />You can do these tasks by trying to inperpret the Bonsai source code yourself, or preferably by finding a person who has intimate knowledge of the Bonsai source code and asking them.
</td>
</tr>
<tr>
<td>Query CVS via Bonsai for checkins</td>
<td>You can use Bonsai to search for the checkins made within a certain time frame, within a certain directory, made by a certain developer, etc. Your mission is to find the relevant source files, functions, variables, etc. that drive this functionality. </td>
<td>TBD.</td>
<td>October 20, 2006</td>
<td>Incomplete.</td>
</tr>
<tr>
<td>Results of querying CVS via Bonsai for checkins</td>
<td>Bonsai obviously returns results from the query. The question is how? Your mission is to find the relevant source files, functions, variables, etc. that is used to return and store results. What you need to find out is what type of data is returned and how are the results formatted?</td>
<td>TBD.</td>
<td>October 20, 2006</td>
<td>Incomplete.</td>
</tr>
<tr bgcolor="#F0F0F0">
<td>Query CVS via Bonsai for version history</td>
<td>For each file in the CVS repository, Bonsai has the ability to list a history of versions. From the first to the latest. Your mission is to find out the relevant source files, functions, variables, etc. that are used to obtain the version history for a certain source file.</td>
<td>TBD.</td>
<td>October 20, 2006</td>
<td>Incomplete.</td>
</tr>
<tr bgcolor="#F0F0F0">
<td>Results of querying CVS via Bonsai for version history</td>
<td>Your mission is to find out the relevant source files, functions, variables, etc. that are used to return and store the results of searching for a file's version history. What data is returned and how is the data stored/formatted?</td>
<td>TBD.</td>
<td>October 20, 2006</td>
<td>Incomplete.</td>
</tr>
<tr>
<td>Query CVS via Bonsai for differences between versions</td>
<td>Using Bonsai, a user can see the differences between two different versions of a source file. Your mission is to find out the relevant source files, functions, variables, etc. that are used to find the differences between two different versions of a source file.</td>
<td>TBD.</td>
<td>October 20, 2006</td>
<td>Incomplete.</td>
</tr>
<tr>
<td>Results of querying CVS via Bonsai for differences between versions</td>
<td>Using Bonsai, a user can see the differences between two different versions of a source file. How are the results returned? How is it formatted? Your mission is to find out the relevant source files, functions, variables, etc. that are used to return the results of the query. You are to find out how the data is returned and how it is formatted.</td>
<td>TBD.</td>
<td>October 20, 2006</td>
<td>Incomplete.</td>
</tr>
</table>
'''[WORK IN PROGRESS: This post will be updated once I gather all of my thoughts. Stay tuned...]'''
