Richard Stallman <[EMAIL PROTECTED]> writes: > My advice would be to delay any improvement (except for fixing > regressions) until you are at the *start* of a development phase. > > We're talking about three kinds of cases: fixing old bugs, fixing new > bugs, and changes that are not bug fixes. You're grouping the first > case with the third; I think it belongs with the second. > > I think it is misleading to describe bug fixes as "improvements". > That word suggests something optional, and bug fixes are not optional.
There are different severities of bugs, though. Fixing a user interface design inconsistency that leads to bad results in marginal cases is to be weighed against the likelihood of the respective fix introducing more severe problems that might go unnoticed before the release. A redesign might in cases be necessary to actually fix a minor bug properly. It might make sense to move that kind of fix to after the next release, and instead document the problem for the current release. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
