On Friday 16 September 2005 15:06, Ben Fowler wrote:
On 9/16/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
This is a "black or white" approach that won't work. Users never want either bug fixes or new features. They want both (and NOW :)).
Speaking personally, a lot of the software that I use evolved their necessary feature set around 10 years ago. I would always vote for quality and bug fixes, and in some cases actual removal of features. Whilst this sounds heretical, this is not a rare and not even an especially unusual point of view.
I think there is still some confusion arising here, from the fact that the "users" who are interested in bug fixes are not the "users" who are interested in a new feature. At the same moment, different people need different things. So yes, both are needed NOW, from different users' points of view, but developers need to prioritise those requests, nonetheless.
I would suggest that fixing existing issues is more important than new features, unless a new feature is going to replace the buggy code anyway. Even obscure bugs can lead to important code cleanups, that make future work easier and better.
This is why I suggest that from a developer's point of view, we either need to be able to slipstream older bug fixes (my thaw policy as outlined above) or have protected releases when we only do bug fixes.
How about having a policy that feature commits happen in a certain ratio to bug fixes? Everyone likes to code new features more than to fix obscure bugs, but if their new feature depended on either them or others getting bugs quashed, it might help to even things out.