[dmd-internals] Oldest five bugs

Leandro Lucarella luca at llucax.com.ar
Wed Jan 18 15:34:56 PST 2012


Jason House, el 18 de enero a las 17:34 me escribiste:
> On Jan 18, 2012, at 4:48 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> 
> > On 1/18/12 3:41 PM, Don Clugston wrote:
> >> From 5 years 8 months to 5 years 6 months. I don't think we get much
> >> leverage from that.
> > 
> > We must start somewhere, and with time the "de-aging" process will accelerate. Without giving old bugs due process, we undermine people's confidence that we're thorough and that every bug will be ultimately looked at.
> > 
> >> We don't have the resources to improve either the number of open bugs,
> >> or the age of the oldest bug, by enough that anybody would care.
> >> By contrast...
> >> 
> >> REGRESSIONS.
> > 
> > I agree regressions are important. But we shouldn't frame things as
> > "either we look at older bugs or fix regressions". I think each
> > release should pay attention to both.
> 
> I agree with Andrei. As D fights to gain popularity, it will be
> evaluated by a variety of somewhat arbitrary metrics by people
> deciding if they should take the D plunge.
> 
> People will definitely look at how quickly bugs get closed. For a new
> language with a recent uptick in community involvement, 6 year old
> bugs are definitely embarrassing.

If people don't "experience" bugs they will not even look at the age of
bugs, they will not even look at the bug tracker! How many times did you
checked the bug from other languages? I use GCC and Python on a daily
basis for years now, and I think I might had a look in their bug
trackers about 2 or 3 times in that time frame. With D I look at it this
many times per month maybe. That's not because I like to see how old
bugs are, but because I get bit by bugs. That are the bugs that should
be fixed first.

> Just like the "no new regressions" policy, a "no bugs more than
> 5 years old" policy might be good too. Having recent updates to old
> bugs by core people would definitely blunt some of it.

You can't compare. The "no regressions" ("new regressions" is kind of
redundant :) policy is a must, no something you do just to make the
"arbitrary metrics" made by random people to judge the compiler's
quality. Again, that will only happen if people find bugs on their daily
use, and that will surely happen if you introduce regressions in new
version.

> Things can also be made to look better with a liberal policy of
> marking old bugs as wontfix as well as consolidating older bugs into
> newer, more general, bugs.

Are you serious? Why don't we just remove all bugs and show people that
D is bug free? Really... you can't be serious...

And again, the age of a bug is only relevant when users actually *hit*
the bug. I agree that if two bugs are equally annoying and important,
the oldest one should be fixed first, that would show the users they
won't have to fight the bugs they *hit* for too long. But it makes no
sense to spend time fixing a bug that nobody cares just because if
6 years old when there is a but that's more important and it's just
4 months old. It also doesn't make sense to close the bug because it's
old, it should be fixed eventually when there is nothing more
important to fix (or when somebody finds fixing that bug particularly
fun, don forget that most of the people do this as a hobby). It doesn't
make any sense to conceal it's age either.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Yo soy Peperino él que nunca toma vino, yo soy aquel que por la mañana
escucha Salatino.
	-- Peperino Pómoro


More information about the dmd-internals mailing list