On Monday, 25 February 2013 at 10:09:18 UTC, Iain Buclaw wrote:
On 25 February 2013 09:35, Don
<[email protected]> wrote:
On Monday, 25 February 2013 at 01:04:01 UTC, Iain Buclaw wrote:
On Feb 24, 2013 10:16 PM, "Walter Bright"
<[email protected]>
wrote:
On 2/24/2013 8:48 AM, SiegeLord wrote:
I am quite sick of DMDFE breaking my code every release
with bugs
that are then solved for the next release (that is, if they
are
solved).
Here's the current regression list:
http://d.puremagic.com/issues/**buglist.cgi?query_format=**
advanced&bug_severity=**regression&bug_status=NEW&bug_**
status=ASSIGNED&bug_status=**REOPENED<http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED>
All regressions should have a link to the commit where the
issue first
recurred.
In my experience, that's nearly always a waste of time. In
almost
all cases, there is nothing wrong with the offending commit, it
merely triggered an existing latent bug. This is particularly
true of forward reference bugs.
I didn't imply that there was anything wrong with the offending
commit.
I didn't intend to imply that you did. My experience is that it
doesn't even have any useful relationship to the bug, and that
(even worse) you waste a lot of time trying to figure out what
the relationship is.
It
does help to give a reference point on where to start looking
for tracing
the different code paths down and find a resolution to the
regression, a
opposed to "removing this line" or "adding this safegaurd seems
to work".
Intuitively, I used to think that, but I personally have not
found that to be true in practice. I think tracking down the
exact commit is a complete waste of time. In the cases I've seen
where it had a clear relationship to the bug, it was obvious what
part of the code contained the bug, anyway.
