1
edit
Changes
→Project Details
Now that we are aware of the different concepts that we must take into account with regards to delta debugging, the next section will outline some facts and assumptions that are being made, and attempt to define the vision and process of the delta debugging framework.
'''Facts and Assumptions:'''
# The source code tree for the Mozilla project is HUGE. With many different source files file types (C++, JS, XUL) in many different directories.# Failure-induces 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 failure-inducing changes change(s) may not be localized to a single developer. The failure-inducing change (s) may have been caused by another developer's change of (s) to a source file they were working on. That is, a single developer's source scope may not be encapsulated but interconnected and interdependent on other developers source code.
# 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 the last known good version number or 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)
'''Possible Vision of the Delta Debugging Framework''':
(subject to change based on stakeholder consultation/feedback, feasibility study)
# 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 of information. One, 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 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.# (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: ## Recursively, incrementally remove changes from the source code with the regression.## Recompile the source tree.## Execute the test case. There may be 3 outcomes:### The test case passes. We know that the failure-inducing change(s) are in the change(s) that were removed. ### The test case fails. We know that the failure-inducing change(s) are not exclusively in the change(s) that were removed. I say not exclusively because of the concept of Interference (described above). ### The test case is indeterminate. There were some inconsistencies.
