I did not mean to imply that a bug to be submitted must be 100% reliably reproducible. The (unfortunate) reality is that many bugs aren't easily or reliably reproducible. Take the race condition on startup for late-run N800s, for instance, whose causes were environmental related and quite bizarre. It's the nature of bugs to often be difficult to reproduce and difficult to fix (if they weren't, it's unlikely that they'd've shipped in the first place).

No, you should just make sure you have as much information as you can gather about the bug when you submit your report.

I don't know if they really want to know, but. . . .

Many bugs do fall into this category, as they're the type that's likely to be missed during normal testing and QA procedures and, thus, to make it into releases, and of course engineers want to ship the most bug free code they reasonably can. The key with reports of this type is to make sure you either get as close to figuring out what reliably reproduces the bug (some seemingly semi-random bugs only seem that way because you've missed a hidden trigger variable, like "it only happens between midnight and 1 AM", or "it only fails when there's an SD card in the slot"*), or provide as much information as you can come up with (even if you don't think it's relevant—if you can't fix the bug yourself you can be reasonably certain that you're not going to be able to accurately judge what might and might not be pertinent ) to give the triager or engineer the best chance of reproducing it themselves.


*This is what was causing sleep failures on my Dell Mini 9, but it took me a while to connect having an Sd card in the slot to failures.