digitalmars.D - Bugzilla issues that are or seem to be resolved
- Stanislav Blinov (5/5) Nov 22 2018 I'll be going through the Bugzilla, at least those issues that
- Stefan Koch (4/9) Nov 23 2018 You could run digger bisect to see at which commit it started
- Stanislav Blinov (5/15) Nov 23 2018 I know I can spend arbitrary time searching for every fix that
- Nicholas Wilson (10/27) Nov 23 2018 run.dlang.io outputs
- Simen =?UTF-8?B?S2rDpnLDpXM=?= (11/16) Nov 23 2018 When I've closed issues like that, it's been WORKSFORME and a
I'll be going through the Bugzilla, at least those issues that I'm confident to look at. There are some that look to be already fixed, like this one: https://issues.dlang.org/show_bug.cgi?id=10641 What's the appropriate procedure for those? Mark as WORKSFORME?
Nov 22 2018
On Friday, 23 November 2018 at 05:33:04 UTC, Stanislav Blinov wrote:I'll be going through the Bugzilla, at least those issues that I'm confident to look at. There are some that look to be already fixed, like this one: https://issues.dlang.org/show_bug.cgi?id=10641 What's the appropriate procedure for those? Mark as WORKSFORME?You could run digger bisect to see at which commit it started passing?
Nov 23 2018
On Friday, 23 November 2018 at 09:25:54 UTC, Stefan Koch wrote:On Friday, 23 November 2018 at 05:33:04 UTC, Stanislav Blinov wrote:I know I can spend arbitrary time searching for every fix that wasn't properly reported on Bugzilla :) What I'm asking is what's appropriate to do when that's not possible/feasible, etc. Just leave it to rot some more years?I'll be going through the Bugzilla, at least those issues that I'm confident to look at. There are some that look to be already fixed, like this one: https://issues.dlang.org/show_bug.cgi?id=10641 What's the appropriate procedure for those? Mark as WORKSFORME?You could run digger bisect to see at which commit it started passing?
Nov 23 2018
Nicholas Wilson <iamthewilsonator hotmail.com> On Friday, 23 November 2018 at 09:41:49 UTC, Stanislav Blinov wrote:On Friday, 23 November 2018 at 09:25:54 UTC, Stefan Koch wrote:run.dlang.io outputs 2.066.0: Failure with output: ----- core.exception.AssertError onlineapp.d(11): Assertion failure [snip stack trace] ----- Since 2.067.1: Success and no output so some time between there. Just close it as fixed.On Friday, 23 November 2018 at 05:33:04 UTC, Stanislav Blinov wrote:I know I can spend arbitrary time searching for every fix that wasn't properly reported on Bugzilla :) What I'm asking is what's appropriate to do when that's not possible/feasible, etc. Just leave it to rot some more years?I'll be going through the Bugzilla, at least those issues that I'm confident to look at. There are some that look to be already fixed, like this one: https://issues.dlang.org/show_bug.cgi?id=10641 What's the appropriate procedure for those? Mark as WORKSFORME?You could run digger bisect to see at which commit it started passing?
Nov 23 2018
On Friday, 23 November 2018 at 05:33:04 UTC, Stanislav Blinov wrote:I'll be going through the Bugzilla, at least those issues that I'm confident to look at. There are some that look to be already fixed, like this one: https://issues.dlang.org/show_bug.cgi?id=10641 What's the appropriate procedure for those? Mark as WORKSFORME?When I've closed issues like that, it's been WORKSFORME and a comment on which version fixed it. If some future software archaeologist wants to figure out exactly which commit did it, that's up to them. Would be cool if we could set up a test case for each bugzilla issue and have it automagically associated with the commit that fixed it... -- Simen
Nov 23 2018