Vakkotaur

This morning Slashdot has an article asking about getting better (useful) bug reports from users. I don't have an answer other than there ought to be more than simply "file a report" and a single acknowledgement. That is, if I do file a bug report (and it is a decent report) then please let me know more, even if it's some time late. I'm much more likely to file another good report (assuming I trip over another bug...) if a previous one was handled well. A simple "this issue has been assigned to a maintainer/developer" helps. If I see the problem corrected, that's ideal. If I get a work-around sent to me, hey that's at least something.

But that does assume I send a good bug report. A good bug report is not "No bugs found." as wonderful as that would be. It's "I'm using this hardware, in this configuration, connected this way, to that thing, and when I do *THIS ACTION* on this program, *THIS* happens rather than *THAT* which was supposed to happen." It's more than "It's broken." It tells someone what sort of hardware is involved (Does Intel have a weird bug? Does AMD? Is that new video card causing trouble?) and what I do to trigger the bug. Did I type something into a certain text box? Did I click something? Is it a matter of which server I was trying to use? It's like going a mechanic with a car problem. You tell the mechanic the symptoms such as "There's a squeak on right turns, especially over about 30 mph." rather than "It's broken. Please fix it."

I used to deal with bug reports and most of the time what I got was the useless, "It's broke, fix it!" crap. Fix what, exactly? There was one customer of the company I worked for that did really good bug reporting. They also got very fast turn-around fixes. When I got a report from them, it was "We've got this model device, running this version software, and when we go into this particular menu and change this particular setting..." And that was often enough to aim me right at the issue they had. It wasn't quite a big red blinking [BUG HERE!] sign, but it was as close as one is ever likely to get. I didn't have to waste time guessing what was going on, I could get right to the issue. It wasn't always easy, but it often shaved hours if not days, weeks, or even months off of a real solution. As much as I disliked having a bug creep in or pop up, if I heard of one that made it past internal testing, I really wanted to hear it from those guys.

A different customer had a complaint that was reported as pretty much "Version 1 works, version 2 doesn't." and wanted changes made to the obsolete (and painful to work on...) version 1. They eventually got that, because I was unable to fix version 2 (which already had the feature they wanted...) since they didn't say exactly what was going on. I'm sure that they thought they did, but I could never duplicate the problem. Months later another customer hit the same problem, but gave detailed information about how to trigger the problem. Then I could duplicate the problem - and only then I could start the actual fixing of the real problem. It was a real, "Damn, why didn't those other guys tell us that bit?!" moment.

Even if you think something isn't important, don't omit it. It might just be the one critical piece that solves everything - or at least pinpoints the actual problem. Until it's checked, all data is valuable. Don't throw it away before it can even be used. Will some be irrelevant? Almost certainly, but you (and perhaps even the folks debugging) don't know which information is critical and which is not. As someone who was trying to hunt down bugs, I'd much rather have had an excess of information than a shortage of it.

Of course, if your experience really is "No bugs encountered." I am fairly sure whoever you're dealing with would love to read that in a review or something.

[ADDENDUM]: And if a developer or maintainer asks a question, PLEASE actually answer the question rather than fill in the background with so much other stuff that foreground goes underground. That was question wasn't asked for nothing.

A couple of those asian beetles, the things that look like orange ladybugs but have bad manners (they bite and they stink) were flying around the office lights last night. When we first switched the lights to CFLs it was odd as some bugs were suddenly not flying around the lights. These beetles do fly by the lights and ping off of the spiral tubes.

I thought I got the one, only to find that there was another. I dealt with that one as well. Then it started snowing, sort of. Little flecks would drift down, like the light fixture was a snow cloud (or had dandruff) and that also got annoying. Stepping away I found that the particles were all coming from the edge of one blade of the ceiling fan. Sure enough, another beetle was walking along on the top of the blade and it was enough to knock some dust down. Even when they aren't flying around me or landing on me, they still find a way to be annoying. Fortunately that was all last night and tonight if there are any of those beetles around, they haven't been annoying me.

After many, many attempts to get Wolvix Linux to use a wireless connection and many, many utter failures to accomplish same, I think it's time to declare Wolvix "not ready for real world use." The Wolvix forum provided some help, but all I managed to get the lights to blink without getting a genuine connection. Wolvix was also not always launching the window manager fully, and didn't connect with a wired connection at first. It did eventually, so at least it seems possible to use it that way. That, however, is pretty useless when the places I'd use the laptop tend not to have sockets to plug into but only wireless access.

It is disappointing as overall Wolvix looks good. Too bad it doesn't seem to actually work.

I suppose, if nothing else, this at least means I won't have to put up with the GNU/ prefix silliness.