How You Talk Yourself Out of Reporting a Bug

I've filed a few bug reports and I can't recall one that ever led to a fix. Most often they just sit there and get closed six months later for lack of activity. Some times they're fixed upstream. I found a bug in `dash` (Debian's replacement for sh, AFAIK.) It had been reported back in 2011 (IIRC) and the fix will finally be released with the next Debian release which will likely be out some time this year. :-/

I almost filed a bug against Visual Studio Code for a problem with `git` integration. One of the requirements for filing the bug is to install the latest development release. That was enough to discourage me. I'll just stick with `git` on the command line.

I filed a bug against one of the Visual Studio Code plugins that has not been fixed. (The extension tries to install a program in a system directory w/out getting root permissions and fails.)

If I thought my bug reports were providing any benefit I'd continue to submit them. (And in the case of VS Code didn't have too many hurdles to submit.)

Irony Of The Day: I realized a critical problem in the post about bug reports. We originally listed the three pieces of a Proper Bug Report as "what you did", "what you expected", and "what you saw" but that misses the most important point of a Proper Bug Report. It's not just the list of steps you took, past tense. The idea is to start from scratch and see if you can make the bug happen on command, writing down each thing you do along the way.

(Blog post now updated, including even the Latin inscription in the title image.)

Love this! I think that you could use that to “debug” more things than just software. Like fixing a broken routine, etc.