Regression Testing Issue

denali · Post by **denali** » Tue Jul 07, 2009 8:06 am

I'm currently in the process of regression testing a bug (http://bugs.winehq.org/show_bug.cgi?id=19219). However, I ran into a problem that http://www.winehq.org/docs/winedev-guide/x1348 doesn't cover.

Say a dev submits a series of patches that rely on each other for something, such as communications. While doing git bisect, some of those patches end up on opposite sides of the bisect. This renders the program unable to communicate with the internet. What do you do in those cases? My solution was to issue a git bisect good, but I'm not sure that was the best solution. My hope is that as I test and continue to issue git bisect good every time the program works correctly, it'll come back around to the set of patches that are causing the issue, but I'm unsure.

Thoughts?

vitamin · Post by **vitamin** » Tue Jul 07, 2009 8:18 am

denali wrote:Say a dev submits a series of patches that rely on each other for something, such as communications. While doing git bisect, some of those patches end up on opposite sides of the bisect. This renders the program unable to communicate with the internet. What do you do in those cases?

First this really shouldn't happen. All patches are required to be atomic and not break any functionality within the series. Unfortunately this is not always the case and some patch series do break things if not fully applied

In those cases you can use

Code: Select all

git bisect skip

Git will pick a different commit to test. Hopefully the series that doesn't work for you is not the source of the regression.

denali · Post by **denali** » Tue Jul 07, 2009 9:20 am

vitamin wrote:
denali wrote:Say a dev submits a series of patches that rely on each other for something, such as communications. While doing git bisect, some of those patches end up on opposite sides of the bisect. This renders the program unable to communicate with the internet. What do you do in those cases?
First this really shouldn't happen. All patches are required to be atomic and not break any functionality within the series. Unfortunately this is not always the case and some patch series do break things if not fully applied

In those cases you can use
Code: Select all
git bisect skip
Git will pick a different commit to test. Hopefully the series that doesn't work for you is not the source of the regression.

Hi vitamin,

Thanks for replying!

This is good to know. If necessary, I'll restart the regression test. I have a feeling the problem is in the series that didn't work for me. However, I'll go all the way to the end and see what happens.

In the meantime, could someone add git bisect skip to the aforementioned wiki article? That would have been TREMENDOUSLY helpful to know. Especially since regression testing is requested on a semi-regular basis.

denali · Post by **denali** » Tue Jul 07, 2009 9:24 am

denali wrote:I'm currently in the process of regression testing a bug (http://bugs.winehq.org/show_bug.cgi?id=19219). However, I ran into a problem that http://www.winehq.org/docs/winedev-guide/x1348 doesn't cover.

Say a dev submits a series of patches that rely on each other for something, such as communications. While doing git bisect, some of those patches end up on opposite sides of the bisect. This renders the program unable to communicate with the internet. What do you do in those cases? My solution was to issue a git bisect good, but I'm not sure that was the best solution. My hope is that as I test and continue to issue git bisect good every time the program works correctly, it'll come back around to the set of patches that are causing the issue, but I'm unsure.

Thoughts?

Not that this matters, but I'm actually working on http://bugs.winehq.org/show_bug.cgi?id=19217 and not 19219. 19219 is someone else's bug. Oops!

Frédéric Delanoy · Post by **Frédéric Delanoy** » Tue Jul 07, 2009 11:52 am

On 07/07/2009 04:20 PM, denali wrote:

vitamin wrote:
denali wrote:
Say a dev submits a series of patches that rely on each other for something, such as communications. While doing git bisect, some of those patches end up on opposite sides of the bisect. This renders the program unable to communicate with the internet. What do you do in those cases?
First this really shouldn't happen. All patches are required to be atomic and not break any functionality within the series. Unfortunately this is not always the case and some patch series do break things if not fully applied

In those cases you can use

Code:
git bisect skip

Git will pick a different commit to test. Hopefully the series that doesn't work for you is not the source of the regression.
Hi vitamin,

Thanks for replying! This is good to know. If necessary, I'll restart the regression test. I have a feeling the problem is in the series that didn't work for me. However, I'll go all the way to the end and see what happens.

In the meantime, could someone add git bisect skip to the aforementioned wiki article? That would have been TREMENDOUSLY helpful to know. Especially since regression testing is requested on a semi-regular basis.

FWIW, you can find a good explanation of git bisect => "man git-bisect"

Frédéic