Confirm
3,816
edits
Changes
no edit summary
See [[Calendar:QA_Links|QA Links]] for Bugzilla queries to unconfirmed bugs.
=== Finding a Regression Range on a Bug ===
Very often something will break in a newer build that worked in a previous version. When this happens, it is always useful to determine the regression range for the bug. This means that you check the nightly builds, and try to find the two successive builds where the bug works in one build, and fails in the next one. From there, we can easily determine what changed in the source code using the [http://bonsai.mozilla.org bonsai tool].
An example using a [http://en.wikipedia.org/wiki/Binary_search_algorithm binary search]:
Let's say that test X worked in version 0.3.1 and did not work in the current nightlies. You find out that 0.3.1 was released on February 23, 2007. So, you start looking at builds to find out when test X stopped working.
1. Check 0.3.1 just to be sure that it did in fact work
2. Check a nightly build created on a date halfway between now and February 23, 2007.
** If test X works on this build, then check it with a nightly that is halfway between this date and the current date.
** If test X fails on this build, then check it with a nightly that is halfway between this date and the date of your last known working build (in this case, February 23, 2007)
Keep halfing like this until you find the date where in the nightly before this date test X worked, and in the nightly built on this date, test X fails.
Here are the locations of nightlies (for lightning - for sunbird, replace "lightning" with "sunbird in the URL")
* Most recent three months of nightly builds are [ftp://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly here]
* From previous months in [ftp://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/2007 2007]
* [ftp://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/2006 2006]
===Testdays and other events===
