Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

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