And the reality is that not all bugs will be fixed. This is true of virtually every large software system. Even the 2 (only 2!) systems that claim to be bug free in the world (TeX and QMail) have pretty large caveats on those claims. QMail, especially, has decided that some weird behaviour is desired -- because no changes are allowed to the original source code (It's not a bug, it's a feature!).
Toady's style has also been to rewrite large sections of the code base rather than refactor it and then expand. This means that over time these bugs will not be fixed, but will disappear and be replaced with other bugs (sometimes a very similar bug).
There are lots of ways to approach software development and each way has its advantages and disadvantages. I once ran a fairly large team (about 60 people) and told them that we were going to write it so that specific functionality was bug free. As we went, we defined what the software would do and we ensured that it continued to work as described -- forever. However, that's far from saying the software didn't contain bugs. It had lots of bugs. As long as the documented functionality was bug free that's all we cared about. I got a *lot* of push back on that project because people cared about ensuring that unanticipated work flows were also bug free. That's quite a rabbit hole, though -- especially in a complex system. You always have to strike a balance. Where you position the balance point depends on a lot of factors.
DF is the ultimate sandbox game so virtually everything is an unanticipated work flow (and it's kind of designed to be that way). There are going to be bugs. I'm not saying that the situation can't be improved, but there will always be a balance in the end.
Author
Topic: 67 pages of 'new' bugs... (Read 1019 times)