No worries, I ended up not having time to do during my talk, but I'll do it over the weekend since now I committed to it :)

I'm just curious about the comment on the first document: "Note, June 2022: For updated guidelines about documenting Go code, see “Go Doc Comments.”

Does this mean that the document is not actively being updated? I still think we should though...

Is anyone working on this? I'm doing a talk tomorrow and I'm looking for a good example to make a very small contribution and this seems perfect for what I want to do. Considering this is just improving the documentation, I suspect we have the consensus that this is the right approach? (LGTM)

Please let me know!

If you want to try implementing it you can just fork this project to your GitHub account and work there. Whenever you feel that you have something that you want to show me you can open a Pull Request (PR) to this repo and I'm more than happy to work with you doing code reviews and polishing the solution.

Just to register my final thought on this, I'm with @iglendd and others. I still don't think that it's the business of the Go runtime to care about if the OS is uploading something or not to a random server, and that falls within the scope of the SysAdmin to decide. That said, I'm also not prepared to die on this hill and I accept the compromise of GOTRACEBACK=wer as it at least gives us an option to do something, instead of the no-op that we have today.

I still think that if a sysadmin configures WER to send logs to Microsoft it is not the role of the Go runtime to bypass that.

For me GOTRACEBACK=crash should do whatever is configured at OS level, without trying to enable or disable anything. Of course, the documentation should make it clear that data might be sent to MS.

On Thu, 9 Mar 2023 at 19:44, Quim Muntal @.***> wrote:

Are you suggesting to automatically disable WER for GOTRACEBACK=crash case if it is not disabled (yet)?

Nop. Go runtime is currently disabling WER for the running process using SetErrorMode (source https://github.com/golang/go/blob/24017148ca8a669debbddba56d69769dc47d5c71/src/runtime/signal_windows.go#L13-L23). That call disables WER crash dump uploads and local dump generation. What I'm saying is to not call SetErrorMode if WER uploads are disabled system-wide and allow WER to chime in.

I do feel strange, on philosophical level, about an application attempting to control (interfere?) how system handles system behavior ...

Completely agree, but I don't want to die on this hill, if the Go community feels that GOTRACEBACK=crash should do its best to not upload anything, then so be it, GOTRACEBACK=wer is a good alternative.

— Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/57441#issuecomment-1462674256, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKGMJEQ4HWJQLVYIVAHKV3W3IXLXANCNFSM6AAAAAATGONT4Y . You are receiving this because you commented.Message ID: @.***>

-- Daniela Petruzalek Software Engineer github.com/danicat twitter.com/danicat83