When will D1 be finished?

[dsimcha]

== Quote from Jason House (jason.james.house at gmail.com)'s article
> Derek Parnell Wrote:
> > On Tue, 12 May 2009 10:13:38 -0700, Walter Bright wrote:
> >
> > > The order of importance of bugs is roughly:
> > >
> > > 1. silently generating bad code
> > > 2. compiler crashes
> > > 3. regressions that break previously working code
> > > 4. not accepting valid code
> > > 5. accepting invalid code
> > > 6. poor error messages
> > >
> > > Throw into that how much work a bug is to fix, how many projects it
> > > affects, if there's a patch submitted, etc.
> >
> > This is useful and important information. IMO it should be on your website
> > ASAP.
> >
> > I think you have forgotten another criteria that should be on this list,
> > the age of a bug report. Although a bug, which doesn't fall into the top
> > priorities here, is old it does not mean that it shouldn't be looked at.
> > From a product perspective you are correct - it is of low importance, but
> > from a client perspective, submitting a bug report which is effectively
> > placed in limbo is a let down - it can cause people to no longer want to
> > help you.
> >
> > A trickle of older bugs being fixed would do wonders for client
> > relationship management - especially those with higher votes.
> >
> > --
> > Derek Parnell
> > Melbourne, Australia
> > skype: derek.j.parnell
> A few other metrics that effect user perception
> 1. Has the assignee ever commented on the bug?
> 2. When will the bug be fixed? Has a milestone been assigned?

One thing I would add to prioritizing bug fixes is how many other bugs the feature
has.  Features that are severely buggy, such as array ops or alias this benefit
relatively little from having a single bug fixed because anyone using those
features still has to constantly remember that they're buggy and keep the
workarounds in mind anyhow.  Furthermore, bugs often overlap in how they limit
functionality in real-world use cases.

On the other hand, features that are pretty well debugged, but still have a few
little gotchas, like variadic templates and auto return (See bug 2251 --you can't
use both at the same time) or ddoc benefit much more from a single bug fix.  Once
these last few remaining issues are solved, these features can be used as
"gotcha-free" and the user need not constantly feel like he/she is walking through
a minefield when using them.