Russ Cox

I updated the image already, just need to submit the CL.

For what it's worth, we have been running api.godoc.org as an unmonitored service (meaning we don't page people for it), approximately "best effort" although even that may be too generous....

I'm not sure about the compatibility claim. If the program was exiting due to unrecovered panic before, now it's not, and it might be in a more broken state as...

This proposal has been added to the [active column](https://golang.org/s/proposal-status#active) of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review...

It seems plausible, although it also seems plausible that it might break things. It would be nice not to incur the expense of recording the stack separately if that's possible...

Based on the discussion above, this proposal seems like a **[likely accept](https://golang.org/s/proposal-status#likely-accept)**. — rsc for the proposal review group

> Under the current proposal, AFAICT, the panic would be silently swallowed if Wait() was never called. This is an interesting point. I will leave this as 'likely accept' for...

Moving back to active. I think the Wait issue needs more discussion and an explicit decision.

This proposal has been added to the [active column](https://go.dev/s/proposal-status#active) of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review...

Keying off the context doesn't seem like the right way to define semantics here. Given that x/sync/errgroup is in x and can be rolled back easily, it seems like maybe...