I Bet He Got His Bug Fixed

Tags: devops

Gather around kids, and listen to a story about a user looking for help. Years ago there was a bug report submitted to the MPlayer project reporting a crash. The user gave a large amount of data to increase the chances of finding a fix. He gave so much data, in fact, that his bug report garnered 15 minutes of Internet fame because of some explicit detail. A Shark’s Tale was on his play list, and if that wasn’t embarrassing enough, he also had some extremely NSFW material right next to it.

MPlayer’s bugzilla installation migrated to a new host years ago, and I suspect they consciously chose to remove or hide the blush-worthy bug. I also suspect that once the childish giggling died down that guy got his bug fixed. Why? Because he provided detail for examination by the developers.

What happens when a bug or support request arrives without enough detail?

I received a vague bug report this afternoon that didn’t contain enough detail to recreate. Over the course of 20 minutes we extracted enough information to solve the problem, but this was only after the ambiguous bug spent the better part of a month in queue with everyone raising an eyebrow, shrugging, and moving on to more fertile debugging pastures.

There’s hardly a thing as too much detail when submitting support requests. Providing sufficient detail sends two signals:

1. You’ve put forth effort to fix things yourself, and, short of that, collect data for the people that will fix things.

2. You value the time of others. The experts assisting you will know which bits to ignore, but they can’t even get started if they don’t get enough info in the first place.

And if you insist on seeing the forum threads reporting on the crazy MPlayer bug report, just search for: mplayer bug report Sharks Tale. But not at work. Or really ever. It’s silly Internet shenannigans.