Sven Baars wrote:
Dmitry Timoshkov wrote:
Maarten Lankhorstm.b.lankhorst@gmail.com wrote:
On 23-05-10 01:57, Dan Kegel wrote:
I think it's a good idea. 'regression' isn't as strong as 'bisected'.
Unless there are objections, I'll add the keyword on Monday.
I think I'll object. I don't see any point in the bisected tag that regression doesn't already cover. As far as I know as soon as you tag something as regression you either already have bisected it, or will be asked to bisect it quickly after adding the regression tag.
Exactly. There shouldn't be not bisected bugs with the 'regression' keyword in the first place.
Exactly. And to make it easier for people to find bugs that do have the regression keyword, but were not bisected, you could add the bisected keyword, so it'd be easier to actually get to the point where all regressions are bisected. In this case, it is not something developers would use directly, but something that would at least make the work of developers little easier.
+1 to this idea. The use of regression without bisected gives those of us that are willing to do the bisect a target and keeps us from duplicating effort. Using the word bisect points out the patch or patches that caused the regression. A good example is when I found a problem moving through about 20 versions + of Wine where an error occurred. The patch author provided a private patch to fix the problem until I reached the version of Wine where it was truely fixed.
Having a bisect helps in troubleshooting and may actually point out that the patch unveiled a code error elsewhere in Wine. This happened on more than one occasion during the last two years.
Adding the bisect 'keyword' also should require that the poster add a commit line (this will require more effort) for the commit that caused/uncovered the regression.
James McKenzie