Confirm
2,959
edits
Changes
no edit summary
= Data =
* QA Testing Data located : https://github.com/mozilla/qa-testcase-data
= Regression Window Process =
The following process summarizes how you can get a regression window for a regression in Firefox OS.
Using knowledge of knowing the last version this bug didn't reproduce on and knowledge of what build you reproduced the bug on, start downloading & flashing builds on the first affected version to your device and reproduce the target bug. If the bug doesn't reproduce, then you move forward in time to download the next build. If the bug does reproduce, then you move backwards in time to download the next build. Eventually, you will get to a point where you've narrowed down the regression range to a 12 hour time span.
At this point, you should look and see if there are tinderbox builds within that target regression range. If there are tinderbox builds available for the target version in question, then you should further bisect this using the same bisection process you did before down to a regressing changeset.
Next, you'll want to determine if the regression was a Gaia or a Gecko regression. This can be done by trying to reproduce the bug on a build with the last working Gaia on top of the first broken Gecko and on a build with the first broken Gaia on top of the last working Gecko. If the bug reproduces on the first broken Gaia with the last working Gecko, then the bug is a Gaia regression. If the bug reproduces on the last working Gaia with the first broken Gecko, then the bug is a Gecko regression. If both tests either cause the bug to either reproduce in both cases, then the testing is inconclusive to determine if it's a Gaia or Gecko regression.
Then, if you've determined that the bug is a Gecko regression, then you'll want to study the push log to see if the regressing changeset came from a b2g-inbound merge. To generate a push log, you'll want to form a link of the following form:
* http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c0f85061c7d3&tochange=cd3e9359fd64
* http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=71a8786c3815&tochange=e8f6bdf8db3d
Where c0f85061c7d3 & 71a8786c3815 are examples of the last working changesets in gecko and cd3e9359fd64 & e8f6bdf8db3d are examples of the first broken changeset in gecko. Next, open the link and check if the regressing changeset was from a b2g-inbound merge. If it was, then you'll want to bisect even further using b2g-inbound tinderbox builds to find the exact regressing changeset.
At this point, you'll have all of the data you need to present a regression window on a bug.
