3 ms·

Can you please explain this? That sounds like identifying bugs but not fixing them but I realize you don’t mean that. One hopes the context information in the e

• rwmj 10mo ago
  Here's an example of a bug that I filed about non-actionable error messages: https://github.com/karmab/kcli/issues/456 https://github.com/karmab/kcli/issues/456 The first error message was "No usable public key found, which is required for the deployment" which doesn't tell me what I have to do to correct the problem. Nothing about even where it's looking for keys, what is supposed to create the key or how I am supposed to create the key. There are other examples and discussion of what they should say in the link. Edit: Here's another one that I filed: https://github.com/containers/podman/issues/20775 https://github.com/containers/podman/issues/20775
  • 1123581321 10mo ago
    That makes sense and good examples; thanks. At work, I can think of cases where we error when data mismatches between two systems. It’s almost always the fault of system B but we present the mismatch error neutrally. Experienced developers just know to fix B but we shouldn’t rely on that.
• Copenjin 10mo ago
  You can hope that the person reading the context will always able to understand it like you would have. Bad assumption in my experience.
  • 1123581321 10mo ago
    Quite true. It can be a bad assumption when I’m the one trying to understand it weeks later. :)