pages tagged bugyakkinghttp://yakking.branchable.com/tags/bug/yakkingikiwiki2018-03-21T12:00:12ZFamous bugshttp://yakking.branchable.com/posts/famous-bugs/Lars Wirzenius2018-03-21T12:00:12Z2018-03-21T12:00:06Z
<p>The history of computing has a number of famous bugs. It can be
amusing to read about them. Here's a start:</p>
<ul>
<li>The very <a href="https://thenextweb.com/shareables/2013/09/18/the-very-first-computer-bug/">first recorded bug</a> (1945)</li>
<li>The <a href="https://en.wikipedia.org/wiki/Mariner_1">Mariner 1</a> crash (1962)</li>
<li>The <a href="https://en.wikipedia.org/wiki/Therac-25">Therac-25</a> radiation overdose (1985)</li>
<li>The <a href="http://www.phworld.org/history/attcrash.htm">AT&T network</a> failure (1990)</li>
<li>The <a href="https://en.wikipedia.org/wiki/Pentium_FDIV_bug">Pentium bug</a> (1994)</li>
<li>The <a href="http://www-users.math.umn.edu/~arnold/disasters/ariane.html">Ariane 5</a> rocket explosion (1996)</li>
<li>The <a href="https://en.wikipedia.org/wiki/Pentium_FDIV_bug">other Pentium bug</a> (1997)</li>
<li>The <a href="https://en.wikipedia.org/wiki/Mars_Climate_Orbiter">Mars climate orbiter</a> crash (1999)</li>
</ul>
<p>What's your favourite bug? Please tell us in comments.</p>
Dealing with bugs against your projecthttp://yakking.branchable.com/posts/bug-handling/Lars Wirzenius2016-10-12T11:00:13Z2016-10-12T11:00:07Z
<p>It was late in the afternoon. The city was in that quiet period
between the lunch time rush hour and the end of work day rush hour.
The sun was getting low in the sky. My office blinds were making
shafts of light that highlighted the dust particles hanging in the
air. I was bored, but looking forward to an early evening date with a
bottle of soda and a video stream to my couch.</p>
<p>Suddenly, <strong>blam</strong>, a letter dropped into my INBOX. Oh, no! So much
for my evening plans.</p>
<p>I took my feet off my desk, and opened the missive. It was a report of
the worst kind: someone's found a bug, and I would have to get off my
gluteus maximus to squash it, and squash it good. I opened my drawer,
and took out the key to the hardware cabinet, and strapped a .33 under
my left armpit. (That's a .33 liter can of cola, not a gun. Using guns
to deal with bugs would be ridiculous, what kind of a thug did you
think I am?)</p>
<hr />
<p>So you have a free software project with users. Sooner or later
someone will report a problem that they're experiencing, and this may
turn out to be an actual bug in your program that you need to fix.
Let's have a short look at how to do that well.</p>
<p>Some recommendations, based on over three decades of writing software:</p>
<ul>
<li><p>You should document how to report issues. Making unhappy users dig
for that information just makes them angry.</p></li>
<li><p>You should separate reports of issues separately from confirmed
bugs. A bug is something you need to fix, an issue is something you
need to investigate what causes it. An issue report is a discussion
to find out what is wrong, and it may or may not turn into a
confirmed bug that causes code changes.</p></li>
<li><p>Try to keep the list of open reports as short as possible, and also
the list of confirmed, but unfixed bugs. Long lists are
de-moralising, and also take effort to pick the next thing to pay
attention to. This is all waste.</p></li>
<li><p>It's good to have a public tracker of issues and bugs. It can be as
easy as a static web page you maintain manually, or it can be
something automated, such as the <a href="https://www.debian.org/Bugs/">Debian BTS</a>, or <a href="https://bugzilla.mozilla.org/">Bugzilla</a>, or
any of the myriad other options.</p></li>
<li><p>Automated trackers tend to enforce some process. Some of them make
this rather heavy, others keep it quite lightweight. For small
projects, lightweight is a much better option. Only add a more
heavyweight process after it's already clearly needed.</p></li>
<li><p>You should probably make it easy to report issues. Some people
prefer to make it less easy in order to avoid too many issues being
reported for trivial things, but my preference is to keep the
threshold as low as possible.</p></li>
<li><p>Whatever you do, treat those who report issues with kindness.
<a href="http://yakking.branchable.com/posts/be-gracious/">Be gracious</a>. Be friendly. Be open to the possibility that you've
made a mistake.</p></li>
</ul>
Reporting bugshttp://yakking.branchable.com/posts/reporting-bugs/Lars Wirzenius2014-04-16T11:00:25Z2014-04-16T11:00:07Z
<p>You will encounter a bug in some softare some day in the future. You
might ignore. You might fix it yourself. You might report it to the
developers of the software.</p>
<p>There's several reasons for reporting bugs.</p>
<ul>
<li>Other people might fix them.</li>
<li>Someone might know of a workaround.</li>
<li>You might learn why the problem you found isn't an actual bug.</li>
</ul>
<p>Glory and fame and fortune are not reasons for reporting bugs,
merely beneficial side-effects.</p>
<p>Many large projects have a page for how to report problems in a way
that is best for that project. Some examples:</p>
<ul>
<li><a href="https://wiki.openoffice.org/wiki/QA/HowToFileIssue">Apache OpenOffice</a></li>
<li><a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines">Mozilla</a></li>
<li><a href="https://fedoraproject.org/wiki/How_to_file_a_bug_report">Fedora</a></li>
</ul>
<p>There are also some generic guides:</p>
<ul>
<li><a href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How to Report Bugs Effectively</a></li>
<li><a href="http://www.catb.org/~esr/faqs/smart-questions.html">How To Ask Questions The Smart Way</a></li>
</ul>
<p>A quick summary, based on the author's experiences:</p>
<ul>
<li>Check that no-one else has reported the problem already.</li>
<li>Explain what you did, what you expected to happen, and what
really happened.</li>
<li>Do not rephrase: use copy-paste, screenshots, and file attachments
to provide the actual output or files that happened.</li>
<li>If at all possible, describe a way to reproduce the problem.
If you can get it reproduced with a shell script, even better.</li>
<li>Be patient. Many large projects receive lots of bug reports, on the
order of tens of thousands per year. It may take a long time for
them to react, and they may not be able to give all their attention
to just your problem.</li>
</ul>
<p>Reporting bugs can be a delightful experience. A reponsive development
team appreciates your report, and fixes the problem immediately, and
thanks you in their release notes. This can be a good route to start
contributing to the project in general.</p>
<p>Reporting bugs can also be a frustrating, de-motivational experience.
Your bug may be ignored, or closed without explanation, or you'll be
told you did something wrong. Just interacting with the project's bug
tracking system can ruin your day. If you interact with enough
projects, you'll encounter these things. If you can, shrug it off and
move on to another project.</p>