re: make "bisected" a keyword in bugzilla?
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.
Hi Dan, 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. Cheers, Maarten
On Sat, May 22, 2010 at 6:55 PM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote:
Hi Dan,
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.
Cheers, Maarten
You know what would be neat? Turn fixing Wine into a game. Give people points for successfully reporting bugs, take points away for reporting duplicates, give more points for successfully bisecting a bug... Erich Hoover ehoover(a)mines.edu
I'm starting to wonder about the use cases for both of those keywords. Personally, I mostly ignore the "regression" keyword. As a developer looking for bugs to work on, I've found it not very useful. At a given point in time, most regression bugs are not easier, more severe, or more important than the others, nor are there (to my knowledge) people who work best on regression bugs. If my name appears in a bugzilla comment (usually because my patch broke something), it gets caught by a gmail filter and I pay attention. If a patch I write causes a regression, it suggests something is wrong or incomplete about the patch, and I should look at it while it's fresh. (I assume that such monitoring is not usually necessary because the patch author will be CC'd. I am unusual because the email address I use to send patches is not the same address I use on bugzilla. Also I use gmail filters obsessively.) The patch that switched gdiplus to builtin by default is an exception. It tells me nothing new. I don't mind seeing the regression keyword on those bugs because I don't use it, and anyway I pay attention to all the gdiplus bugs. So, at least for those I cause, it helps if regressions are found and bisected as soon as possible, so that the original patch is fresh in my head. I know Wylda has been bisecting regressions that others have reported, and if adding a keyword makes that easier, I'm all for it. Does it? Perhaps the ability to search for non-bisected regressions would be useful, since bisecting is something that anyone with the ability to build wine and access to the software can do. I believe it's also time-critical, because: * As time goes on, it gets harder to build old versions of Wine on modern distributions, because new versions of build tools tend to break things. Wine accumulates build fixes that are not present in old versions. * The more time passes since the patch was originally written, the more likely it is that the author has moved on. * Even when the author is still around, it's easier to work on recent regressions than old ones. Perhaps, if we could easily see which regressions still need to be bisected, someone could make it a goal that all newly-reported regressions are bisected within a few months. When an unbisected regression starts to get stale, perhaps someone could post something on wine-users like "Does anyone own <product name>? It has a regression that needs bisecting." But that's not something I would do. I'm a developer, not a community manager. Anyway, I think we should talk about how people use the regression keyword now, and how they would use this new keyword, and that should determine whether it gets added.
Used to say here... Don't teach old eagle to fly :) Same way i shouldn't teach developer how to write patch and for which bug. For this reason (as i said before) i can live without BISECTED.
Personally, I mostly ignore the "regression" keyword.
That's OK if you have a proprietary system of work based on gmail filters etc. But from a manager point of view, i would care if i have a transparent system independent of particular poeple. People can leave for so many reason, then they need to be easyly replaced with new ones. And if previous developer dies and can't resend you content of his unfinished mail folder, you loose continuity because of such proprietary... Other than that, if wine gets high quality, manager might want to keep that quality. So not accepting cleaning and other "moving box" patches till he sees that that all bisected gets closed (fixed or reverted) for particular developer. And because it don't need to be programmer but quite simple human understandig BISECTED&CLOSED=GOOD, he could find a BISECTED keyword as handy ;) Also if you have too old Bisected, you could loose the ability to revert easily (even for developers). So another reason why to watch BISECTED.
...and if adding a keyword makes that easier, I'm all for it. Does it?
Now i usualy try to process UNCONFIRMED & REGRESSION, but i think it would be better to have an easy link to filter unbisected regressions. Also in previous post we talk with Nikolay, why Maarten's indeas of REGRESSION==BISECTED can't work. But don't want to teach old eagles to fly ;)
Ideally all regressions would be bisected, but that's clearly not the case. You can of course argue about terminology and / or mechanism, but I think it's useful to distinguish "possible" regressions from confirmed regressions with a commit id. Personally I think it would be nice if bugzilla could give me a list of commit id's and associated bugs, so I could use git and some scripting to do additional processing on that. Perhaps the real issue is that the list of regressions is large enough that it becomes somewhat impractical to go through them on a regular basis to look for regressions that aren't bisected yet though. There are currently 338 bugs with the regression keyword, of which 64 have the directx-d3d or directx-ddraw component. I'm currently CC'd on 10 of those, most of which are not so easy to fix for one reason or another. In my personal experience, the majority of regressions aren't necessarily a problem with the original patch, but rather existing problems becoming more visible, etc. Perhaps that's different between different developers and different components though. It doesn't really matter who's fault a particular regression is though, what it comes down to is that you touched something, and now it's broken. So if I'd be reviewing a wined3d patch from someone, I'd balance the likelihood of that patch / developer breaking something versus how likely it is that that developer is going to fix it in a timely fashion when it does break.
Henri Verbeet <hverbeet(a)gmail.com> wrote:
Ideally all regressions would be bisected, but that's clearly not the case. You can of course argue about terminology and / or mechanism, but I think it's useful to distinguish "possible" regressions from confirmed regressions with a commit id. Personally I think it would be nice if bugzilla could give me a list of commit id's and associated bugs, so I could use git and some scripting to do additional processing on that.
Probably it would be better to add a field for commit id that caused a regression just like there is one for url/keywords instead of inventing new keywords. So a 'regression' with a commit id would automatically mean 'bisected'. That would also save time of finding the commit id by looking at every comment in the bug, and possibly avoiding finding incorrect bisect results. -- Dmitry.
On Sun, May 23, 2010 at 11:53 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
Henri Verbeet <hverbeet(a)gmail.com> wrote:
Ideally all regressions would be bisected, but that's clearly not the case. You can of course argue about terminology and / or mechanism, but I think it's useful to distinguish "possible" regressions from confirmed regressions with a commit id. Personally I think it would be nice if bugzilla could give me a list of commit id's and associated bugs, so I could use git and some scripting to do additional processing on that.
Probably it would be better to add a field for commit id that caused a regression just like there is one for url/keywords instead of inventing new keywords. So a 'regression' with a commit id would automatically mean 'bisected'. That would also save time of finding the commit id by looking at every comment in the bug, and possibly avoiding finding incorrect bisect results.
If editing Bugzilla's layout is easy to do, I like this option. -- -Austin
Probably it would be better to add a field for commit id that caused a regression just like there is one for url/keywords instead of inventing new keywords. So a 'regression' with a commit id would automatically mean 'bisected'. That would also save time of finding the commit id by looking at every comment in the bug, and possibly avoiding finding incorrect bisect results.
Yay, that would be even better!
On Sun, May 23, 2010 at 22:45, Wolfram Sang <wolfram(a)the-dreams.de> wrote:
Probably it would be better to add a field for commit id that caused a regression just like there is one for url/keywords instead of inventing new keywords. So a 'regression' with a commit id would automatically mean 'bisected'. That would also save time of finding the commit id by looking at every comment in the bug, and possibly avoiding finding incorrect bisect results.
Yay, that would be even better!
While doing some other bugzilla maintenance, I've found where to add custom fields, so a 'regression commit sha1-id' (or other preferred name) field is now a possibility. I'll wait a week for comments before adding it. -- -Austin
On 28/07/11 22:15, Austin English wrote:
On Sun, May 23, 2010 at 22:45, Wolfram Sang <wolfram(a)the-dreams.de> wrote:
Probably it would be better to add a field for commit id that caused a regression just like there is one for url/keywords instead of inventing new keywords. So a 'regression' with a commit id would automatically mean 'bisected'. That would also save time of finding the commit id by looking at every comment in the bug, and possibly avoiding finding incorrect bisect results.
Yay, that would be even better!
While doing some other bugzilla maintenance, I've found where to add custom fields, so a 'regression commit sha1-id' (or other preferred name) field is now a possibility.
I'll wait a week for comments before adding it.
Yay! \o/
On Mon, Aug 1, 2011 at 03:28, Wolfram Sang <wolfram(a)the-dreams.de> wrote:
On 28/07/11 22:15, Austin English wrote:
On Sun, May 23, 2010 at 22:45, Wolfram Sang <wolfram(a)the-dreams.de> wrote:
Probably it would be better to add a field for commit id that caused a regression just like there is one for url/keywords instead of inventing new keywords. So a 'regression' with a commit id would automatically mean 'bisected'. That would also save time of finding the commit id by looking at every comment in the bug, and possibly avoiding finding incorrect bisect results.
Yay, that would be even better!
While doing some other bugzilla maintenance, I've found where to add custom fields, so a 'regression commit sha1-id' (or other preferred name) field is now a possibility.
I'll wait a week for comments before adding it.
Yay! \o/
Done. -- -Austin
Maarten Lankhorst <m.b.lankhorst(a)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. -- Dmitry.
Dmitry Timoshkov wrote:
Exactly. There shouldn't be not bisected bugs with the 'regression' keyword in the first place.
Just to get an idea how close the bugzilla is to the above, I tried to query the database how many bugs have 'regression' but no bisect. Alas, no success so far, even something simple like "keyword==regression AND substring!=commit" (pseudo-code), doesn't work for me; giving up for now. Like Wylda, I still think it is useful, but will accept if it is too much of a burden(?) for you, of course. Regards, Wolfram
Dmitry Timoshkov wrote:
Maarten Lankhorst<m.b.lankhorst(a)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.
Sven Baars wrote:
Dmitry Timoshkov wrote:
Maarten Lankhorst<m.b.lankhorst(a)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
participants (11)
-
Austin English -
Dan Kegel -
Dmitry Timoshkov -
Erich Hoover -
Henri Verbeet -
James McKenzie -
Maarten Lankhorst -
Sven Baars -
Vincent Povirk -
Wolfram Sang -
wylda＠volny.cz