From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Matthias Dahl Newsgroups: gmane.emacs.devel Subject: Re: wait_reading_process_ouput hangs in certain cases (w/ patches) Date: Thu, 15 Mar 2018 15:59:50 +0100 Message-ID: <2e181861-cfb8-a461-dfb6-9fee2164a611@binary-island.eu> References: <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> <83y3iur4jo.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1521125935 20745 195.159.176.226 (15 Mar 2018 14:58:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 14:58:55 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: eggert@cs.ucla.edu, larsi@gnus.org, rrandresf@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 15 15:58:51 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 1ewULC-0005Jj-Pd for ged-emacs-devel@m.gmane.org; Thu, 15 Mar 2018 15:58:51 +0100 Original-Received: from localhost ([::1]:51985 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ewUNF-0004ee-Sl for ged-emacs-devel@m.gmane.org; Thu, 15 Mar 2018 11:00:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ewUMJ-000490-Vg for emacs-devel@gnu.org; Thu, 15 Mar 2018 11:00:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ewUMG-0008EL-SV for emacs-devel@gnu.org; Thu, 15 Mar 2018 11:00:00 -0400 Original-Received: from ud19.udmedia.de ([194.117.254.59]:33470 helo=mail.ud19.udmedia.de) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ewUMG-0008Ck-H5 for emacs-devel@gnu.org; Thu, 15 Mar 2018 10:59:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=binary-island.eu; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=k1; bh=XF FyqjDtl6Cd9Zwv/3T0I8H5L5WESyn92LmxbHUaht8=; b=hHdApuY0a/oeDmjUHS qCfJC8vh9ayPTZIMdXthUQLfR9pTQLN3YK+K3zYfr/8qxUbtEPdgTJxX7kaJQpD+ CK1MTKonqseQcYnYj/LSWbNum9ZBvzmokc1vAJKhMrD7kxIHdpkopvIdb+xFTNCt XDJuI7NWBqsRNHn/8EID4Bmzw= Original-Received: (qmail 27205 invoked from network); 15 Mar 2018 15:59:53 +0100 Original-Received: from unknown (HELO ?IPv6:2a02:810b:c540:234:36aa:25b9:ca8f:d05f?) (ud19?126p1@2a02:810b:c540:234:36aa:25b9:ca8f:d05f) by mail.ud19.udmedia.de with ESMTPSA (ECDHE-RSA-AES128-GCM-SHA256 encrypted, authenticated); 15 Mar 2018 15:59:53 +0100 Openpgp: id=1E87ADA02EFE759EFC20B2D1042F47D273AA780C In-Reply-To: <83y3iur4jo.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 194.117.254.59 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:223741 Archived-At: Hello Eli... On 14/03/18 17:43, Eli Zaretskii wrote: > 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. I understand and mostly agree with your reasoning... with the exception that I think known bugs should be fixed before a stable release is made if they cross a specific severity level. And I guess that is the point where we somewhat disagree: The severity level of the bugs in question. :) If we were both on the same page about that, I strongly believe we would also agree on that actions without any doubt. > OTOH, the > problems fixed by the proposed changes are (a) relatively rare, and > (b) have been with us for many years. And I am honestly not so sure about (a). Just because we don't see many reports on the list, does not mean those issues don't surface themselves in day-to-day usage for the users in strange and unpredictable ways that get blamed on packages or whatnot. It is hard to quantify this... > 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. And I am glad I am in no position to have to make that balancing act. But I fully get where you are coming from. And your more conservative approach is probably for the better. And like I said, if we agreed on the severity of the bugs discussed, we probably wouldn't even be having this discussion at all since I think we mostly have the same opinion. > 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. Dmitry was kind enough to point me towards Emacs' test suite which I'm now having a close look at. I really did not know that even existed. I will be trying to come up with tests for the bugs and as usual, also do the necessary commenting on the code to make things clear that are not as obvious from the code itself (like bug references, ...). In general, maybe, it would be a good idea to actual put a stronger emphasis on getting a test case for each bug fix, where possible. That would increase test coverage considerably over time and help prevent regressions like this one. > Same here, obviously. I never doubted that for a picosecond. :-) To make one more thing clear: We really don't have to discuss this any further. You are probably having better things to do and I don't want to steal your time. And like I said, no matter what decision is made, it is really fine by me. I don't want to cause any trouble... Thanks again for your patience, Matthias -- Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu