Re: Emacs 27.1 released

[Mattias Engdegård]

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.