Re: Emacs 27.1 released

["Mattias Engdegård" <mattiase@acm.org>]

14 aug. 2020 kl. 15.28 skrev Eli Zaretskii <eliz@gnu.org>:

> I actually didn't consider the code at all in this case, I tried to
> approach the issue from the POV of risk management.

I understand what you mean, but it is not very different from what a maintainer fixing a bug does; assessing consequences and risks is part of the job.

> What bothers me is the risk of having the fix uncover as yet unknown
> problems in the callers of the function that was fixed.  Do you have
> any thoughts about that?  For example, if the callers are already
> broken when the fixed function misbehaved (are they?), that would be a
> strong argument to cherry-pick the changes, because they cannot
> possibly break what is already broken.

Well, there is no indication that callers of calcFunc-gcd are of particularly low quality. Solid tests would have helped, of course: were Calc written today we would have insisted on a very different degree of test coverage, but that was not the standard coding practice at the time. Without spending the time to build a full test suite for the considerable amount of functionality of Calc, the best we can do is to fix bugs using careful analysis and good habits and add well-targeted tests for the flaw and nearby code without succumbing to exponential explosion. We then sit back and wait until we believe time has tested it.

On the other hand, Calc is fairly easy to validate in the respect that it's often just a matter of doing what is mathematically correct and things will sort themselves out. Anything going wrong after fixing one part was therefore almost by definition already broken. It was not quite what you meant, but perhaps it gives a partial answer to your question.

That said, none of the bug fixes mentioned were of high importance. The way Emacs development works, it's likely better to encourage users to build and use Emacs master rather than back-porting anything to a stable branch.