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?

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?

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'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?

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?

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

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:
>> 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?
>
> 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?

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.