Hi,
I noticed that Wylda uses "--private keyword: bisected" when appropriate. IMHO this could be useful as a real keyword, e.g. if you search for bugs you'd like to try tackling. Has this been considered already?
Regards,
Wolfram
Wolfram Sang wolfram@the-dreams.de wrote:
I noticed that Wylda uses "--private keyword: bisected" when appropriate. IMHO this could be useful as a real keyword, e.g. if you search for bugs you'd like to try tackling. Has this been considered already?
There is a keyword 'regression', that should be enough.
Wolfram Sang wolfram@the-dreams.de wrote:
I noticed that Wylda uses "--private keyword: bisected" when appropriate. IMHO this could be useful as a real keyword, e.g.
if you search for bugs you'd like to try tackling. Has this been
considered already?
There is a keyword 'regression', that should be enough.
Hi, it depends, if regressions are considered as bugs of top priorites.
I would wish, if they could be considered, because killing them early means, that quality of wine is not getting worse during the ongoing development.
Imagine, that someone used to have a working game in 1.1.42 and his distro offers him upgrade to 1.1.44. He goes ahead with upgrade and apps stops working. He fills in a bug - UNCONFIRMED & REGRESSION keyword. Then someone other have exactly the same problem, so confirms that and we have the bug with NEW & REGRESSION. So something serious, which should attract dev's attention. But when developer begins to work on that, he spends some time with getting the demo, verifies it's behaviour and then finds out, that the problem is wrong Ubuntu package. So his time with this bug was wasted.
Compare this with regressions which are bisected (aka "bug served on silver tray"), so saves a lot of time. And of course such a keyword would help in dev's triage what to fix first.
Of course this has a sence and helps only if _truly_confirmed_ regressions are taken seriously, i.e. fixed as first. But Wine is still not in this state.
On 5/23/2010 00:50, wylda@volny.cz wrote:
Wolfram Sangwolfram@the-dreams.de wrote:
I noticed that Wylda uses "--private keyword: bisected" when appropriate. IMHO this could be useful as a real keyword, e.g.
if you search for bugs you'd like to try tackling. Has this been
considered already?
There is a keyword 'regression', that should be enough.
Hi, it depends, if regressions are considered as bugs of top priorites.
I would wish, if they could be considered, because killing them early means, that quality of wine is not getting worse during the ongoing development.
Imagine, that someone used to have a working game in 1.1.42 and his distro offers him upgrade to 1.1.44. He goes ahead with upgrade and apps stops working. He fills in a bug - UNCONFIRMED& REGRESSION keyword. Then someone other have exactly the same problem, so confirms that and we have the bug with NEW& REGRESSION. So something serious, which should attract dev's attention. But when developer begins to work on that, he spends some time with getting the demo, verifies it's behaviour and then finds out, that the problem is wrong Ubuntu package. So his time with this bug was wasted.
I believe developer's attention doesn't depend on bug state (confirmed/uncofirmed) at all.
The flow is to try to fix regressions caused by your own patches if it's not too complicated and there's nothing more serious to do at this point. If it's too complicated to fix fast and a lot of apps (potentially) affected a change is reverted.
Compare this with regressions which are bisected (aka "bug served on silver tray"), so saves a lot of time. And of course such a keyword would help in dev's triage what to fix first.
Actually a "regression" keyword supposes to mean exactly the same. It just happens that it's added every time someone decided to add it. IMO it should be added only when regression test results are available but this isn't going to happen of course for obvious reasons (some reporters don't bother to respond in months). If no test was performed a developer will see a report anyway, searching for a module of interest.
Of course this has a sence and helps only if _truly_confirmed_ regressions are taken seriously, i.e. fixed as first. But Wine is still not in this state.
Compare this with regressions which are bisected (aka "bug served on silver tray"), so saves a lot of time. And of
course such a keyword would help in dev's triage what to fix first.
Actually a "regression" keyword supposes to mean exactly the same. It just happens that it's added every time someone decided
to add it. IMO it should be added only when regression
test results are available
I wouldn't like it either. Because i cherry pick regression keyword or bug reports which looks like regression. So it would bit me, if REGRESSION would disappear as a choice for reporter.
but this isn't going to happen of course for obvious reasons (some reporters don't bother to respond in months). If no test was performed
a developer will see a report anyway, searching for a module of
interest.
I still think that REGRESSION != BISECTED, but i don't argue or enforce such usage. I'll quietly do it my way till someone will tell me "stop that mess in bugzilla". Then i would leave completely...
I try to do my best and i'm a bit sad seeing unfixed "Bisected" for a long time and don't know how to help further :-/
On 5/23/2010 01:22, wylda@volny.cz wrote:
Actually a "regression" keyword supposes to mean exactly the same. It just happens that it's added every time someone decided
to add it. IMO it should be added only when regression
test results are available
I wouldn't like it either. Because i cherry pick regression keyword or bug reports which looks like regression. So it would bit me, if REGRESSION would disappear as a choice for reporter.
Yeah, it isn't a solution of course to ignore it. And it won't disappear.
but this isn't going to happen of course for obvious reasons (some reporters don't bother to respond in months). If no test was performed
a developer will see a report anyway, searching for a module of
interest.
I still think that REGRESSION != BISECTED, but i don't argue or enforce such usage. I'll quietly do it my way till someone will tell me "stop that mess in bugzilla". Then i would leave completely...
Yes, it isn't equal, it's a fact unfortunately.
I try to do my best and i'm a bit sad seeing unfixed "Bisected" for a long time and don't know how to help further :-/
It isn't so simple to fix it sometimes, that's most likely a reason. So I'm sure your time is not wasted, and test results are very useful. And I want to thank you for that.
but this isn't going to happen of course for obvious reasons (some reporters don't bother to respond in months). If no test was performed
a developer will see a report anyway, searching for a module of
interest.
I still think that REGRESSION != BISECTED, but i don't argue or enforce
That was my main point. REGRESSION is the status before the bisect, BISECTED is after, being a lot more narrow. For someone who likes to tackle a bug once in a while, this can make a huge difference. For me, bisecting is not exactly thrilling. So, BISECTED would be the connection point for people like Wylda (doing bisects) and me (doing code).
Regards,
Wolfram
Nikolay Sivov <nsivov <at> codeweavers.com> writes:
I believe developer's attention doesn't depend on bug state (confirmed/uncofirmed) at all.
I'm not sure about that, my experience is that some developers do care about regressions and some don't (actually i think that they missed the bug reports where the regressions are reported) . It would help at least that if those who don't, drop a little message that they saw the bugreport and are aware of the regression they caused ( or if their patch just was correct, and just revealed another wine-bug, add that information)
Actually a "regression" keyword supposes to mean exactly the same.
I don't agree about that, "regression" means the app doesn't work anymore, that could also be because of a distro-upgrade or a mis-configured system at the user side. Bisected means someone with same system+distro has pinpointed the exact patch that caused trouble. So this should have top-priority for wine-devs to look at, if wine wants to get mature.
Louis Lenders wrote:
Nikolay Sivov<nsivov<at> codeweavers.com> writes:
I believe developer's attention doesn't depend on bug state (confirmed/uncofirmed) at all.
I'm not sure about that, my experience is that some developers do care about regressions and some don't (actually i think that they missed the bug reports where the regressions are reported) . It would help at least that if those who don't, drop a little message that they saw the bugreport and are aware of the regression they caused ( or if their patch just was correct, and just revealed another wine-bug, add that information)
Actually a "regression" keyword supposes to mean exactly the same.
I don't agree about that, "regression" means the app doesn't work anymore, that could also be because of a distro-upgrade or a mis-configured system at the user side. Bisected means someone with same system+distro has pinpointed the exact patch that caused trouble. So this should have top-priority for wine-devs to look at, if wine wants to get mature.
Wouldn't it be easier to have both the regression and the bisected keyword, not only to determine the importance of a bug, but also to make the lives of people like Wylda easier? There are bugs that have been marked as regressions that haven't been bisected, and it would be great if people could easily find those bugs and bisect them. AFAIK, we have at least 50 bugs like this ATM.
Also, while we're at it, I was wondering why Wylda doesn't have Bugzilla rights yet. He has been doing an awesome job so far.
On Sat, May 22, 2010 at 3:41 PM, Louis Lenders xerox_xerox2000@yahoo.co.uk wrote:
Nikolay Sivov <nsivov <at> codeweavers.com> writes:
I believe developer's attention doesn't depend on bug state (confirmed/uncofirmed) at all.
I'm not sure about that, my experience is that some developers do care about regressions and some don't (actually i think that they missed the bug reports where the regressions are reported) . It would help at least that if those who don't, drop a little message that they saw the bugreport and are aware of the regression they caused ( or if their patch just was correct, and just revealed another wine-bug, add that information) ...
I know I've had trouble a couple times finding the correct bugzilla account to add the relevant developer. People using a different email for bugzilla than for wine-patches can be very frustrating, you would think that there would be some sort of better way than the email-only system to identify the appropriate developer and tag him for the CC list. I've only been on the developer side of a regression bug once, but it seemed like having a relevant bisect where the reporter was able to identify me as the offender helped a lot toward resolving the issue quickly.
Erich Hoover ehoover@mines.edu
Hello,
On 22-05-10 17:15, Wolfram Sang wrote:
I noticed that Wylda uses "--private keyword: bisected" when appropriate. IMHO this could be useful as a real keyword, e.g. if you search for bugs you'd like to try tackling. Has this been considered already?
I don't think that keyword is needed, since there is already a keyword 'regression' for this.
Cheers, Maarten
-
Dmitry Timoshkov -
Erich Hoover -
Louis Lenders -
Maarten Lankhorst -
Nikolay Sivov -
Sven Baars -
Wolfram Sang -
wylda＠volny.cz