From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: wait_reading_process_ouput hangs in certain cases (w/ patches) Date: Wed, 14 Mar 2018 18:43:39 +0200 Message-ID: <83y3iur4jo.fsf@gnu.org> References: <206ebefa-7583-f049-140c-c8fd041b0719@cs.ucla.edu> <709614e8-1937-07c1-f554-b453ed4f3d4a@binary-island.eu> <7550438b-9fd4-d374-e571-8bb16456cad5@cs.ucla.edu> <797d0e16-1bae-50c2-35f8-05489ffce935@binary-island.eu> <83tvugdiu5.fsf@gnu.org> <877er5s0xv.fsf@gmail.com> <4e4c72bb-295d-81e1-e4ed-cad256bca83c@binary-island.eu> <87zi3v9461.fsf@gmail.com> <87k1uy8x68.fsf@gmail.com> <6d1970af-8c5c-20ba-be09-0b9aa757d663@binary-island.eu> <13b3e003-d12b-33a7-3ebe-c07b017a7cc0@binary-island.eu> <833714rm3d.fsf@gnu.org> <7b64afc3-e9b0-536d-1e42-a5f5d74f1adf@binary-island.eu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1521045747 31604 195.159.176.226 (14 Mar 2018 16:42:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Mar 2018 16:42:27 +0000 (UTC) Cc: larsi@gnus.org, rrandresf@gmail.com, emacs-devel@gnu.org, eggert@cs.ucla.edu To: Matthias Dahl Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 14 17:42:22 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ew9Tq-00086r-Hd for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2018 17:42:22 +0100 Original-Received: from localhost ([::1]:47316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ew9Vr-00054H-N1 for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2018 12:44:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ew9VF-0004de-3H for emacs-devel@gnu.org; Wed, 14 Mar 2018 12:43:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ew9VA-0007UW-7f for emacs-devel@gnu.org; Wed, 14 Mar 2018 12:43:49 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ew9VA-0007UL-44; Wed, 14 Mar 2018 12:43:44 -0400 Original-Received: from [176.228.60.248] (port=1418 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ew9V9-0007tq-Ed; Wed, 14 Mar 2018 12:43:43 -0400 In-reply-to: <7b64afc3-e9b0-536d-1e42-a5f5d74f1adf@binary-island.eu> (message from Matthias Dahl on Wed, 14 Mar 2018 10:56:33 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223727 Archived-At: > Cc: larsi@gnus.org, rrandresf@gmail.com, eggert@cs.ucla.edu, > emacs-devel@gnu.org > From: Matthias Dahl > Date: Wed, 14 Mar 2018 10:56:33 +0100 > > Normally I would fully agree. But we are not talking about new features > here but fixes to bugs that cause sporadic and hard to pinpoint erratic > behavior and hangs possibly all over the place. It is pure chance and > the packages you have installed, if you run into those several times a > day or really never. Fixing bugs runs a certain risk of introducing new bugs. The risk could be small or not so small, depending on the code where the fix is made, the complexity of the fix, and our ability to anticipate the consequences. This is why, as pretest progresses, and the code base becomes more and more stable, we progressively raise the bar and allow only fixes that are less and less risky. > What I am trying to say: Is it really better to keep those bugs around > for another year or more until master becomes the next stable release > just based on the pure chance that we might (or might not) introduce > breakage? Or should we commit the fixes now (and fix current/real bugs > this way) while we're still in the beta cycle and deal with any fall-out > now (which might not even be needed after all). Dealing with fallout in this case means delaying the release, because it takes time for issues in this kind of code to surface. OTOH, the problems fixed by the proposed changes are (a) relatively rare, and (b) have been with us for many years. > Imho, the later is the right thing to do (famous last words :P). We can > fix the fall-out, if any should happen. That's what beta release are for > and it is better to fix that now instead of in a year's time or so and > have users deal with those bugs until then. The current beta is supposed to be the last one. Installing these changes means significant additional delays in releasing Emacs 26.1. We have been pretesting Emacs 26 since September: how many more moons are we prepared to wait in order to have one more bug fixed? That's the balance we should all be considering. > Regarding the regression pointed out by Robert: I'm sorry that happened. > There were no comments or anything. :( I don't blame you. Such regressions in tricky code such as this one are almost inevitable. The question is what do we learn from such experiences regarding the probability of introducing other similar bugs due to these changes, ones that we won't be so lucky to find as quickly as this one. (If you are familiar with the "error seeding" technique for estimating the amount of unknown bugs, it does something similar.) > I only have the user's best interests at heart and what ever you > decide is fine by me. No offense meant or whatever. :) Same here, obviously.