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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Matthias Dahl <address@hidden>
> 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.