From: Daniel Colascione <address@hidden>
Date: Mon, 29 Aug 2016 09:26:38 -0700
Cc: address@hidden, address@hidden
We are talking about code that runs virtually
unchanged for many years. Making significant changes in it needs a
good reason. When such good reasons emerge, we can discuss whether
they justify the risks. For now, the reasons presented do not.
What criteria are you using to determine whether a bug is sufficiently
serious to fix? What would convince you that a change in this behavior
is warranted?
I described up-thread what would constitute a good enough reason for
me to consider such changes for admission. Here's the list again:
. a bug that affects (i.e. breaks) the core code itself (e.g., see
bug#5131 fixed in 00b6647 as a recent example related to insdel.c)
. a problem that affects several Lisp packages for which there's no
reasonably practical workaround/fix as part of the package itself
. refactoring done as part of introducing a significant new feature
Please note that not every change/bugfix is required to pass such
scrutiny, only changes in code that is very central to Emacs
operation. I think manipulation of buffer text, display engine, basic
file I/O, and encoding/decoding stuff are such areas. Changes that
affect some aspects of more local, specialized behavior are normally
less risky. IOW, there's still a judgment call needed in each case,
so that the above is applicable to as few changes as possible.