From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs 27.1 released Date: Fri, 14 Aug 2020 16:28:57 +0300 Message-ID: <83eeo9l5k6.fsf@gnu.org> References: <87a6z2ds3y.fsf@petton.fr> <834kp9ox92.fsf@gnu.org> <87ft8smgje.fsf@gmx.de> <83k0y4ndwz.fsf@gnu.org> <83bljfolp8.fsf@gnu.org> <01498CD4-5E25-4785-941C-D6E9A100ED7F@acm.org> <837du3oh2w.fsf@gnu.org> <83y2mjn00q.fsf@gnu.org> <7248DF65-C427-4D10-AD48-3240B3EF66A7@acm.org> <83v9hllq83.fsf@gnu.org> <02BFD331-A68B-4BD1-85D7-37413056E52B@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39522"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 14 15:29:35 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k6Zm2-000AAo-FP for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Aug 2020 15:29:34 +0200 Original-Received: from localhost ([::1]:57968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k6Zm1-0001lS-HK for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Aug 2020 09:29:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k6ZlZ-0001L5-07 for emacs-devel@gnu.org; Fri, 14 Aug 2020 09:29:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57370) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k6ZlY-00014Y-Mn; Fri, 14 Aug 2020 09:29:04 -0400 Original-Received: from [176.228.60.248] (port=3317 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k6ZlX-00054t-Do; Fri, 14 Aug 2020 09:29:04 -0400 In-Reply-To: <02BFD331-A68B-4BD1-85D7-37413056E52B@acm.org> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Fri, 14 Aug 2020 14:51:31 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:253766 Archived-At: > From: Mattias Engdegård > Date: Fri, 14 Aug 2020 14:51:31 +0200 > Cc: emacs-devel@gnu.org > > 14 aug. 2020 kl. 08.02 skrev Eli Zaretskii : > > > We are assessing this from two very different points of view: you are > > thinking about fixing the bug, and I'm thinking about the dangers of > > some unintended consequences of the fix destabilizing Emacs 27.2's > > version of Calc. By their very nature, unintended consequences are > > unknown to you and to me, so asking for any specific details is not > > useful. > > Sorry about the misunderstanding -- no malice intended. Version history indicates that you were the one bringing Calc into the Emacs tree and did quite some work on it at the time, so it would be daft to assume that you didn't have good knowledge of the code. In other words, there may very well be something you know about it that I could learn. I actually didn't consider the code at all in this case, I tried to approach the issue from the POV of risk management. > However, I understand that you have made up your mind. If you can look at the issue from my POV, and provide arguments relevant to the risks of back-porting these changes, I'd appreciate that very much, as that would allow me to have a second opinion. 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. IOW, I'm trying to weight the advantages of fixing a problem against the potential dangers and risks, especially the unknown ones. Any help in this decision-making will be appreciated.