stability

[Alexander Panek]

Walter Bright wrote:
> John Reimer wrote:
>> In the case of gcc, the other way to look at the bug count (4265) is 
>> to realize that the number is the combined sum of four front ends (C, 
>> C++, Objective C, GNAT) and two processor IS targets (32 bit and 64 
>> bit).  At least that is what I gathered from the link. So I think it's 
>> just a little unfair to compare dmd's bug count directly to gcc's, 
>> although I understand the point you were trying to make. :)
> 
> Bug count is an uninformative measure of quality anyway. For example, if 
> feature A is not implemented, that's a bug. But if A is implemented, yet 
> has a couple obscure problems with it, one bug has been replaced by two. 
> Does that mean the quality has gone down?

Neither. The feature is not implemented properly, it's kind of counter 
productive to argue about the quality of some not implemented or broken 
feature. It would be better to discuss the progress of implementing or 
fixing a feature.

> As soon as someone starts using the bug count as a measure of quality, 
> people start "working" the bug count, and several things start happening:
> 
> 1) people avoid putting bugs into the database

 From personal experience, I can say that this is not the case in the 
environments I have worked in so far. In every single of them, bug 
reports are highly appreciated. Especially because there is some sort of 
analogy to TDD: keeping the lights green is a good motivator.

> 2) people argue about whether bug 114 is really one bug or 3 separate bugs

This can be good under some circumstances. E.g., if this bug says "I 
cannot open the file X with your tool Y", it can be caused by several 
things in given tool. Why not split it up into several bugs in the bug 
tracker to let different people work and comment on it? IMHO, splitting 
up stuff into smaller junks increases productivity, thus motivation, 
thus productivity, etc - you get my drift.

> 3) people argue about whether bug 543 is a bug or an enhancement

What's wrong with that? Classification is important and helps 
prioritizing work, especially in teams.

> 4) people will log a bunch of trivial bugs, then immediately 'fix' them,
> so they look like they're doing impressive work
> 5) people won't work on the hard bugs, because no matter how much time
> it takes to fix it, it will only count as "1" fix, and the other guy who 
> fixed 3 typos gets credit for "3" fixes.

A guy like you shouldn't be working with such immature people. :)

> I had another experience where I once published the outstanding bug list 
> on the C++ compiler as a service to the users of it. One lazy journalist 
> then did a comparative compiler review, and his review of my compiler 
> consisted of little more than a cut&paste of the bug list. I never did 
> that again.

Seems like one should always have a balance between "'Tis so shiny!" 
documentation and issue tracking..

> These sorts of things is what made me very reluctant to use bugzilla for 
> D. Fortunately, these days people seem to have moved past naive bug counts.

Personally, I don't really see open source projects without a public 
issue tracker as well managed.. after all open source software lives 
from user feedback, right? Also, you may find workarounds for your 
specific problem in the comments of a bug report -- or the other way 
round: find confirmation of bugs that may be easier to reproduce for 
yourself.

To conclude: I don't see bug count per se as quality measurement, rather 
response time and interactivity with the development team of a project 
(from a user, as well as contributor point of view). These qualities are 
pretty easy to spot via some issue tracking software (comments, fixes, 
workarounds, etc.) and give people a way of monitoring the development 
process. The latter can especially be important in situations where 
people have to decide what tool to use for their next project(s) -- and 
we all want this to be D! :)