3
edits
Changes
m
== Project Source Repository ==
([[#top|↑ top]])
Assuming you have [http://subversion.tigris.org/ SVN], the project's source can be obtained via SVN using the following command:== Project Test Cases ==
svn checkout svn://cdotThe test cases used in this project are located in the [[Delta_debugging_testcases|Delta Debugging Testcases page]].senecac.on.ca/deltadbg
<table style="width: 100%;" class="standard-table" border="1" cellpadding="2" cellspacing="0"> <tr><td colspan="4"><strong>Priority Legend</strong></td></tr> <tr style="color: #FFFFFF; font-weight: bold; text-align: center"> <td bgcolor="#8B00FF" style="width: 33%;">High Priority</td> <td bgcolor="#0000FF" style="width: 33%;">Medium Priority</td> <td bgcolor="#008080" style="width: 33%;">Low Priority</td> </tr></table><br /><table style="width: 100%;" class="standard-table" border="1" cellpadding="2" cellspacing="0"> <tr><td colspan="4"><strong>Status Legend</strong></td></tr> <tr style="font-weight: bold; text-align: center"> <td bgcolor="#00FF00" style="width: 33%;">Task completed</td> <td bgcolor="#FFFF00" style="width: 33%;">Task started but not complete</td> <td bgcolor="#FF0000" style="width: 33%;">Task not started</td> </tr></table><br /><table style="width: 100%;" class="standard-table" border="1" cellpadding="0" cellspacing="0"> <tr> <th>Task</th> <th>Description</th> <th>Priority</th> <th>Assigned to</th> <th>Status</th> </tr>[[Delta Debugging Framework Roadmap|Delta Debugging Framework Roadmap]]
<tr> <td colspan="5"><strong>Source Documentation The page outlines our current vision of the delta debugging framework and a roadmap of the work that needs to be completed to accomplish our vision. This roadmap may be subject to change and Licensing</strong> </td> </tr>or expanded as our vision expands through feedback and requests from others, our own ideas, etc.
<tr> <td>Source Documentation</td> <td>Unsurprisingly, the source code is not thoroughly documented. Before the end of this semester, by the time the project is due to be submitted, the source code needs to be well documented. </td> <td bgcolor="#008080" style="color: #FFFFFF; font-weight: bold; text-align: center">Low</td> <td>Nobody</td> <td bgcolorPartial Class Diagram =="#FFFF00">There is some documentation in the source files but not much. And it's not well documented.</td> </tr>
<tr> <td>Source License</td> <td>As per the requirements, the delta debugging framework will be licensed under an open source license. Which one? we don't know yet. Though, before the due date of the project, we must select one and change the source files header comments as per the selected license's requirements.</td> <td bgcolor="([[#008080" style="color: #FFFFFFtop|↑ font-weight: bold; text-align: center">Low</td> <td>Nobody</td> <td bgcolor="#FF0000">Not started.</td> </tr>top]])
<tr> <td colspan="5"><strong>Unit Tests</strong> </td> </tr>[[Image:Dd_partialclassdiagram2.PNG]]
<tr>
<td>Unit tests for the various parts of the delta debugging framework.</td>
<td>It would be nice to have unit tests that thoroughly tests each part of the framework to ensure the correctness of the functions. It would be nice to have unit tests for each different part:
# Change/Changeset hierarchy of files
#Build-related files
#RCS-related files
#Test framework related files
#Delta Debugging Algorithm module
</td>
<td bgcolor="#008080" style="color: #FFFFFF; font-weight: bold; text-align: center">Low</td>
<td>Nobody</td>
<td bgcolor="#FFFF00">There are some unit-like tests that tests parts of the framework. However, they are either not thorough or outdated.
# ChangesetTest.pl tests some of the functionality of the Change/Changeset hierarchy of classes. However it is not thorough and outdated.
# maketest.pl tests some of the functionality of the Build classes. However, it is not thorough.
# svntest.pl tests some of the functionality of the RCS classes. However, it is not thorough.
# DeltaDebuggerTest.pl tests some of the functionality of the delta debugger module. However, it is not thorough.
</td>
</tr>
<tr> <td colspan="5"><strong>Change set / Change</strong> </td> </tr>= Project News ==
<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 bgcolor="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td> <td>([[User:RichardChu#top|Richard Chu↑ top]]</td> <td bgcolor="#00FF00">Currently can retrieve change sets of type Revision, Directory, and File. NOT going to complete retrieval of Code Block, Line of Code change set. </td> </tr>)
<tr> <td>Application of Change / Change set</td> <td>OK''This is where your regular updates will go. Change sets can be retrieved. Now what? You must be able to apply a change In these you should discuss the status or change set or subset your work, your interactions with other members of a change set to the source treecommunity (e.g. Your mission is to figure out how to do that, Seneca and Mozilla), problems you have encountered, etc.</td> <td bgcolor="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td> <td>[[User:RichardChu|Richard Chu]]</td> <td bgcolor="#00FF00">Can apply a changeset Put detailed technical information into the Project Details page (specified by array of indices passed ini.e., update it as you go) for a Revision, Directory, and File Changeset. NOT going to complete application of Code Block or Line changesetsave this section for news about participation in the project. </td> </tr>''
<tr> <td>Unapplication of Change / Change set</td> <td>Changesets obviously must be able to be applied=== Dec. But changesets must also be able to be unapplied. Your mission is to figure out how to do that.</td> <td bgcolor22, 2006 ="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td> <td>[[User:RichardChu|Richard Chu]]</td> <td bgcolor="#00FF00">Can unapply a changeset (specified by array of indices passed in) for a Revision, Directory, and File Changeset. NOT going to complete unapplication of Code Block or Line changeset. </td> </tr>
<tr> <td colspan="5"><strong>GNU Make</strong> ([http://wwwI finally had some time to do a second round of testing & debugging of the delta debugging framework.gnuAnd guess what? It ''seems'' to work now.org/software/make/ http://wwwThe problem? Combination of logical errors when applying and unapplying changes in the framework and a bad test case.gnuGo figure.org/software/make/]) </td> </tr>
<tr> <td>Wrapper around However, before I get ahead of myself and officially tag and release the GNU make utility</td> <td>Mozilla uses the GNU make utility delta debugging framework as version 0.1, I would like to build their source treetest it out on another test program. your mission is to make a wrapper around the GNU make utility so that the make command Hopefully, this can be programmatically called to build the source treedone this weekend.</td> <td bgcolor="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td> <td>[[User:RichardChu|Richard Chu]]</td> <td bgcolor="#00FF00">Wrapper created: ''makewrapper And if all goes well, version 0.pl''. Can execute 1 will be officially released before the make command with options specified by end of the useryear. </td> </tr>
<tr>
<td colspan="5"><strong>Subversion (SVN) Repository</strong> ([http://subversion.tigris.org/ http://subversion.tigris.org/], [http://svnbook.red-bean.com/nightly/en/index.html http://svnbook.red-bean.com/nightly/en/index.html])
</td>
</tr>
<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 bgcolor="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td>
<td>[[User:RichardChu|Richard Chu]]</td>
<td bgcolor="#00FF00">Wrapper created: ''svn.pl''. Currently has subroutines for ''commit'', ''update'', ''diff'', and ''checkout'' commands. May need to wrap other SVN commands.</td>
</tr>
<tr> <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=== Dec. 13, and how this data can be parsed into a usable form for our project (wrapper?).</td> <td bgcolor2006 ="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td> <td>[[User:RichardChu|Richard Chu]]</td> <td bgcolor="#00FF00">Done.</td> </tr>
<tr> <td colspan="5"><strong>CVS/Mozilla Bonsai</strong> ([http://wwwUnfortunately, we haven't had the time to test the delta debugger much since Dec.mozilla.org/bonsai.html http://www.mozilla.org/bonsai.html]09, 2006 because of exams, [http:other school work; Planning to spend some time this weekend to test the delta debugger and figure out why it currently seems to not be able find the minimal set of failure inducing directories//cvsbook.red-bean.com/OSDevWithCVS_3E.pdf CVS Book]files (whether its because of unreliable test case or logical error in the program)<br />In my mind, Bonsai may be too bloated for our needs. </td> </tr>
<tr> <td>Wrapper around A roadmap of our vision of the necessary CVS commands</td> <td>For direction of the automated debugging to work, we may need to automatically modify project will be heading in the working copy by reverting to a different revision or updating certain directories future will be created and filesposted soon. It may also need to know the differences between revisions and changesets.</td> <td bgcolor="#0000FF" style="color: #FFFFFF; font-weight: bold; text-align: center">Medium</td> <td>[[User:dwwoodsi|Dean Woodside]]</td> <td bgcolor="#FF0000">Just starting out.</td> </tr>
<tr>
<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 bgcolor="#0000FF" style="color: #FFFFFF; font-weight: bold; text-align: center">Medium</td>
<td>[[User:dwwoodsi|Dean Woodside]]</td>
<td bgcolor="#FF0000">Just starting out.</td>
</tr>
<tr> <td colspan="5"><strong>Test Case(s)</strong> ([http://www== Dec.mozilla.org/tinderbox.html Tindexbox])</td> </tr>11, 2006 ===
<tr> <td>Creation / Extraction of Test Case(s)</td> <td>We need Uploaded testcase for '''HelloWorld''' binary at '''deltatest svn'''. The test cases simulates the error that can return whether or not the test passes or may occur when compilation failsdue to syntax error. Tinderbox has a couple of tests that are executed after The exalted HelloWorld program is located on the HelloWorld directory, while the source test definition is builtat HelloTestCase1. Extract those tests from the Tinderbox source code so that we can use them in this projectpm. We also need a test case that can pass/fail consistently so that we can The algorithm detects failed test and reverts the affected file to the delta debugger.</td> <td bgcolor="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td> <td>[[User:Ankuswan|Aditya Nanda Kuswanto]]</td> <td bgcolor="#FFFF00">Work in progress. Found version where the tests! Now need to figure out how to run them and how they worktest passes.</td> </tr>
<tr> <td>Test Framework</td> <td>We ideally need a way to allow users to specify Note for the test(s) to be run easily without them having to modify the delta debugging module. </td> <td bgcolor="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td> <td>[[Userfuture:RichardChu|Richard Chu]]</td> <td bgcolor="#FFFF00">Work in progress.</td> </tr>improve user feedback functions!
<tr>
<td colspan="5"><strong>Obtaination of Test Repositories</strong></td>
</tr>
<tr> <td>Obtaination of test SVN Repository</td> <td>We have an SVN repository that holds our delta debugging framework source files. We need another SVN repository that we could use to test our framework=== Dec.</td> <td bgcolor10, 2006 ="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td> <td>[[User:dwwoodsi|Dean Woodside]]</td> <td bgcolor="#00FF00">Done. The URL to the test SVN repository is: svn://cdot.senecac.on.ca/deltatest</td> </tr>
<tr> <td>Obtaination of test Where is the CVS Repository</td>Bonsai work heading? Here is a breakdown of the past 3-4 weeks: <td>When the * Initially was going for a straight wrapper around CVS version of ala the framework is completed, style Richard used for SVN.* Tried to find some functionality within Bonsai that could make it will be useful easier.* Talked to have Reed Loden, he set up a test CVS repository for us to try with. Thanks Reed!* Thought that there may be some additional (read: unpublished) tools that we could use to test our frameworkbe worked with.</td> <td bgcolor= Got in contact with some of the "#0000FFProject Participants" style="color: #FFFFFF; font-weight: bold; text-alignlisted on [http: center">Medium</td> <td>[[User:dwwoodsi|Dean Woodside]]</td> <td bgcolor="#00FF00">The CVS repository has been createdwww. The URL is heramozilla.senecacorg/projects/bonsai/].on Was told the person in particular wasn't a contributor (just submitted a bug report).ca They in turn pointed me to [irc:43900/deltatest/irc.mozilla. <br org/>The web interface to the repository is: #mozwebtools #mozwebtools].* Lurked on [httpirc://herairc.senecacmozilla.org/#mozwebtools #mozwebtools] for a few weeks. Talked to 'justdave' about Bonsai. Reed Loden chimed up and informed me that Bonsai can output to XML using ?xml=1 onthe query (score! thanks again).ca* Researched some PERL parsing utilities. Trying out XML::43080/viewvcLibXML for DOM-style parsing.cgi/?root=deltatest here]</td> </tr>* Hopefully wrap something up by Wednesday. Failing that, might just go with simple CVS wrapper of some sort.
<tr>
<td colspan="5"><strong>Implementation of Delta Debugging Algorithm</strong> ([http://www.infosun.fmi.uni-passau.de/st/papers/tr-99-01/ Yesterday, my program worked. Today, it does not. Why?])<br />
</td>
</tr>
<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 bgcolor="#8B00FF" style="color: #FFFFFF; font-weight: bold; text-align: center">High</td>
<td>[[User:RichardChu|Richard Chu]]</td>
<td bgcolor="#FFFF00">Work in progress. Currently, it can theoretically find the failure inducing revision, and the minimal failure inducing set of directories, and the minimal failure inducing set files. It will also easily find the minimal failure inducing set of code blocks and lines of code (if those changeset types ever get done) with only minor additions to one subroutine. Works in theory. Untested in practice.
</td>
</tr>
</table>
== Points of Confusion ==
([[#top|↑ top]])=== Dec. 09, 2006 ===
When I get confused, I draw diagramsWhat has been done since last week?* Got a test program and uploaded it to svn://cdot.senecac.on.ca/deltatest. The pristine working version is revision 4. The latest committed copy is revision 8. The regressive code was committed somewhere in between. * Started testing the delta debugging framework.
[[Image:Dd_partialclassdiagram.PNG]]'''Finding the minimal revision set/last known good revision'''
The RCS tree Indeterminate. There is straight forward. It will encapsulate only 1 directory in the data and operations related to source repository so that directory should be returned as the revision control systemminimal failure inducing set of directories. SVN wraps the operations of the SVN revision control system, CVS will wrap the operations of the CVS revision control system, etcDoes it return it? yes and no.
'''The Blurry: Current Points of Confusion'''However, if I force the test case to return the expected result, then the delta debugger correctly returns the directory as the failure-inducing one.
RCS's can remember the changes I suspect (deltasor at least hope) that occurred in previous versions the indeterminate results of finding the failure inducing set of directories is because of a filepossibly unreliable or inconsistent test case. However, I can not be sure until I rule out the history of changes that occur between revisions, etctest case as the problem.
A Changeset and its subclasses will encapsulate '''Finding the idea of a set of changes. A minimal failure-inducing set of changes could be broken down into various categories such as a specific revision, a list of directories, a list of files, a list of blocks of code, and finally a line of code.'''
A Change and its subclasses encapsulate Indeterminate. There are multiple source files in the repository. Does it return the idea of a single changecorrect failure-inducing source file? I don't know. A change can be a change made within a I have the same suspicions for this as for the directory, change made within a file, change made to block of code, or a change to a linechangeset.
A ChangesetFactory is supposed to return a change set based Based on the type testing, it seems to be able to cycle through every combination of change set requested. To get changes in the requested change setchangeset, one needs to know apply the type combination of revision control system (SVNchanges, CVS, otherbuild the source code, etc.) and/or run the data required to connect to it. So there obviously need a link between RCS and ChangesetFactory/Changesettest case. The question is how? What is the proper/best way to link them together? One way is to pass in an RCS object to the ChangesetFactory which would then pass that object test case just seems to not report the appropriate Changeset subclass. I don't like that solution but it's the simplestcorrect test results.
Also, the method to get a change set for SVN may be different from CVS. So there may be a Changeset hierarchy for SVN and another one for CVS. I don't like the idea of that at all. There must be another way.
'''The Blind: Future Points of Confusions'''
* Applying a change in a changeset=== Dec. Should the Changeset subclasses be able to do that? Are they the information expert? They know about the changes. Should they know how to apply them? How would we go abouts applying a subset of changes in a changeset? For example, there may have been changes in 10 different directories, how would we apply the changes from say 4 of the 10 directories and not the others?* Connecting all 3 hierarchies together. Need to be able to connect to SVN03, need to be able to get and apply changes, need to be able to build the source tree. * The actual delta debugging algorithm. 2006 ===
But Committed some updated to the SVN repository.* The test framework. There are a couple of files to the framework: Test.pl, TestCase.pl, TestSuite.pl, TestResult.pl, TestRunner.pl. It is loosely based off of the design of the JUnit framework. Why such an elaborate design just for the need of users to define the test case that can determine whether or not a piece of functionality works or not to be run? For a few reasons that I may be adamant about:# To use the delta debugging framework, the user should not have to touch the DeltaDebugger.pl file to define the tests and how to run them. Using the testing framework, this can be done by subclassing the TestCase.pl class and overriding the run() subroutine.# For the delta debugger to work, it needs to know whether the test case passes or fails. Using the test framework, I hope to control the possible return codes of the tests to either pass or fail only.* testtest.pl that's all for tests the functionality of the test framework.* updates to DeltaDebugger.pl to make use of the futuretest framework.
== Project News ==
(Crunch time. One week left. The high priority tasks that still need to be done:# Acquisition of a program we could use to test the delta debugging framework. See [[#topHow_to_Get_Involved|↑ topHow To Get Involved]])for more info.# Test, debug the delta debugging framework.
''This is where your regular updates will go. In these you should discuss the status or your work, your interactions with other members of the community (e.g., Seneca and Mozilla), problems you have encountered, etc. Put detailed technical information into the Project Details page (i.e., update it as you go), and save this section for news about participation in the project.''
=== Nov. 26, 2006 ===
([[#top|↑ top]])
[http://en.wikipedia.org/wiki/Delta_Debugging Delta debugging] is an automated approach to debugging that isolates failures systematically. Given a failing test that can be mechanically verified (including a browser crash), [http://en.wikipedia.org/wiki/Delta_Debugging delta debugging] is a way of automatically isolating the change that introduced the failure. Having For developers, the occurrence of a scenario similar to this happens all too often: a developer codes a piece of functionality that works. Then, over a period of time, multiple changes to the program source files are made and that piece of functionality stops working. The cause of the regression could be any of the changes that were made since the time the functionality was last known to work. To isolate the cause of the regression, the developer begins the debugging process. Generally, debugging is a manual process where the developer must walk through the code while trying to keep track of variables and function calls. Sure, there are debuggers that can help you keep track of variables, the call stack, watch certain blocks of code, and execute the code step by step, however debugging is still mainly a manual process. Written in perl, given# that the source code is located in an SVN repository (support for CVS in the future)# a test case that can automatically verify whether or not a piece of functionality of a program works or not# a way to automatically build the program from the source code (if needed)the delta debugging framework aims to automatically isolate the failure-inducing changes to the source code that caused a regression. == Project License == Written in place perl, given a test case that can automatically verify whether or<br />not a piece of functionality of a program works or not, the delta debugging<br />framework aims to pull builds from CVSautomatically isolate the failure-inducing changes to the<br />source code that caused a regression.<br /><br />Copyright (C) 2006 Richard Chu, Aditya Nanda Kuswanto, bisect Dean William Woodside<br /><br />This program is free software; you can redistribute it and/or modify it under<br />the terms of the GNU General Public License as published by date and change set the Free Software<br />Foundation; either version 2 of the License, or (using at your option) any later<br />version.<br /><br />This program is distributed in the hope that it will be useful, but WITHOUT<br />ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS<br />FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.<br /><br />You should have received a copy of the GNU General Public License along with<br />this program; if not, write to the Free Software Foundation, Inc., 59 Temple<br />Place, Suite 330, Boston, MA 02111-1307 USA<br /><br />[http://enwww.wikipediaopensource.org/wikilicenses/Bonsai_CVS_code_management_system bonsai ] data gpl-- remember, CVS doesn't have changesets!license.php The GNU General Public License (GPL)Version 2, and report results would let computers make developers more productiveJune 1991]<br /><br />Contact Information about the authors of the delta debugging framework can be found<br />on our individual profile pages.
== Project Leader(s) ==
''Name(s) of people casually working on the project, or who have contributed significant help. Include links to personal pages within wiki. <br />NOTE: only Project Leader(s) should add names here. You '''can’t''' add your own name to the Contributor list.''
[[User:Reed|Reed Loden]] - Setup the CVS repository for us with the web front-end. Provided direction in querying Bonsai (a means to extract the output in XML).<br>
[[User:Elichak|Liz Chak]] - Documentation of the subroutines in the svn.pl and makewrapper.pl source files.
== Project Source Repository ==
([[#top|↑ top]])
Assuming you have [http://subversion.tigris.org/ SVN], the project's source can be obtained via SVN using the following command:
svn checkout svn://cdot.senecac.on.ca/deltadbg
The source can also be obtained at the following links:
* [http://matrix.senecac.on.ca/~rchu2/ddf/ddf.zip Delta Debugging Framework.zip]
* [http://matrix.senecac.on.ca/~rchu2/ddf/ddf.tar.bz2 Delta Debugging Framework.tar.bz2]
The test cases can be obtained via SVN using the following command
svn checkout svn://cdot.senecac.on.ca/deltatest
The source can also be obtained at the following links:
* [http://matrix.senecac.on.ca/~rchu2/ddf/deltatest.zip DeltaTest.zip]
* [http://matrix.senecac.on.ca/~rchu2/ddf/deltatest.tar.bz2 DeltaTest.tar.bz2]
== Project Details ==
# Once this is done, the framework will deliver the cause of the failure in a report for the user and the operation is finished.
== Project Task List Roadmap ==
([[#top|↑ top]])
Most of the classes in blue exist in the source repository. The classes in pale yellow are classes that won't be completed in the first release.
I haven't posted an update in a while. So what's been done?
Created [[Delta_debugging_testcases|Delta Debugging Testcases]] page to discuss the nature of the test cases created to test the algorithm. Included in the page are 2 testcases created so far, the '''HelloWorld''' binary test and the '''Sudoku''' test. Both tests can be found in the '''deltatest''' svn repository. The repository can be checked out using this command:
<pre> svn checkout svn://cdot.senecac.on.ca/deltatest </pre>
Exactly 12 days before Christmas, the delta debugging framework has been released under the [http://www.opensource.org/licenses/gpl-license.php GPL Version 2] License.
The results of the testing?
Works. The delta debugger correctly reverts to a previous revision, builds the source code, and runs the test case. The test case returns the proper results on whether or not it passes or fails. The delta debugger correctly stops at revision 4 - the last known good version.
'''The Clear: Seemingly Straight ForwardFinding the minimal failure-inducing set of directories'''
The Build delta debugger correctly applies all of the changes within that directory. And I think it correctly builds the source tree and runs the test case. However, the return code of the test case is straight forwardnot as expected. It wraps I expect the build tool used test case to build report that the test fails, however, it reports that it passes. Thus, the source treedelta debugger returns no directories as failure inducing.
=== Nov. 26, 2006 ===
Committed some updates to the SVN repository.
* Updated the delta debugging algorithm module. I didn't realize this yesterday but the algorithm to find the minimal set of failure inducing files (and code block and line of code changes if those changeset types ever gets dones) is the same (with minor modifications) as the algorithm that can find the minimal set of failure inducing directories. Thus I generalized that algorithm to remove the directory changeset specific code so that it will work with all other types of changesets.
* Removed the debugging/test related code from the source files.
CVS Repository Setup (thanks to [[user:reed|Reed Loden!]]): '''hera.senecac.on.ca:43900/deltatest'''
*[http://hera.senecac.on.ca:43080/viewvc.cgi/?root=deltatest ViewVC Web Repository Browser]
*If you want commit access for whatever reason, email one of the project members
=== Nov. 25, 2006 ===
I haven't posted an update in a while so here goes. What's been done since then?
=== Nov. 19, 2006 ===
The earlier crash case we had (see the update directly below) was a non-regressive bug--there was no former build that worked with it.
=== Nov. 18, 2006 ===
*<strike>Found a suitable crash case thanks to the people of [irc://irc.mozilla.org#qa #qa] (in particular, asqueella and Aleksej). For full details on the bug, see [https://bugzilla.mozilla.org/show_bug.cgi?id=354300 Bug #354300].</strike>
Please check back in a few days. Expect some templates and samples up shortly to help get you going. <u>The currently listed test types are subject to change.</u>
==Future of the Project==
Here are some of the ideas related to the continuation of this project. Included are some personal ideas of the team members, tasks to reach the overall objective (a working, robust, Delta Debugging Framework for Mozilla), and additional features/functionality that would enhance the framework. This is subject to change, and a project roadmap will be written in the near future.
===CVS Support via Bonsai===
For the exploration into Bonsai and to see where it is/was heading, please view the [[delta debugging framework bonsai direction|Bonsai Direction]]. It is likely that a workable solution could be produced utilizing some of the details found in the link. This functionality would be particularly useful to Mozilla as this [Bonsai] is the technology they currently use.
===Enhancement of the Algorithm===
Richard's great algorithm can be further enhanced using a binary search-like approach that splits the revision from the current, all the way back to when the regression was first noticed (or, alternatively, when the crash case last known to have worked). Currently it works in a sequential manner, testing all previous revisions in order.
:'''More Granularity'''
:For this course, Richard's algorithm supported down to the file-level of change. In the future, it could go as far as evaluating changes in lines of code.
===Fleshed Out Test Suite Design===
The test suite test types should be further fleshed out and individual tests gathered (no participation from the class was possible due to time constraints; the test suite design wasn't fully explored and documented). Test suites could be put together for each major Mozilla.org project (Firefox, Thunderbird, Sunbird, Bugzilla, etc.).
===More Crash Cases===
More crash cases need to be found for the success in testing the project.
===Unit Tests===
A debugging framework, more so than other projects, should have its code quality tested and scrutinized heavily.
===Code Review===
Perhaps some manual audits could be performed by hand from outside contributors in the future.
