What's In a Bug?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

What's In a Bug?

Casey Ransberger-2
I couldn't help writing the below; I would love feedback on it, as I think I might turn it into a HelpTopic. In particular, it clearly wants a bit at the end about "where to file a bug," but I think the language about the mailing list below is okay; people with post bugs to the list regardless of how anyone feels about it:)

WHAT'S IN A BUG

One day, you will be Squeaking away happily, and something unexpected will happen. It could be something subtle, or it could be something really ugly: the VM might even crash. In any such case, you've found a bug.

A dynamic programming environment like Squeak is a little different from a traditional shrink-wrapped application in that the bug you've found quite likely belongs to you. Before reporting an issue, it's a good idea to see if you can reproduce the problem in a fresh image of the same version. If you can't reproduce the issue in a fresh image, it's probable that you yourself have broken something. It's okay! Spend some time trying to figure out what's going wrong and why. Dig in and see what you can learn about the problem; anything you are able to learn this way will assist you in better communicating the problem if you do decide to ask someone in the community to help you. Just remember, the people in the community are just Squeakers like you, and are not employed or otherwise obligated to help you.

On the other hand, if you can regularly reproduce the problem with a fresh image, you mat have found a bug in Squeak. If you do find a bug in Squeak, you should dig right in! Learn whatever you can about it. See if you can figure out how to fix it: there's nothing more satisfying than fixing a bug you've found yourself, except perhaps for sharing it with your friends on the mailing list. It's okay if you aren't able to fix the bug yourself, but before posting to the list, it's good to make sure you've checked the following boxes:

- Write a general description of the problem.
- Supply (as exactly as possible) the steps you use to reproduce the problem.
- Explain what you expected to happen.
- Explain what actually happened.
- If the bug produces a crash, it's really helpful to include a stack trace.
- If the bug has a visible component or effect, obtain a screenshot.
- Note the version of the Squeak image that you are using.
- Note version of the virtual machine you are running on.
- Specify the operating system you are using.

The above activities will help the community narrow down what might be going wrong. Above all, steps to reproduce the problem are the most critical component to debugging. Without a way to reproduce an issue, it's almost impossible to conduct a fruitful investigation of it.

(INSERT CLOSING PARAGRAPH ABOUT WHERE AND HOW TO ACTUALLY FILE THE BUG)

--
Casey Ransberger


Reply | Threaded
Open this post in threaded view
|

Re: What's In a Bug?

Chris Muller-3
Sounds great for a developer getting into Squeak, encouraging a good
attitude and reasonable expectations..

On Thu, May 13, 2010 at 7:35 PM, Casey Ransberger
<[hidden email]> wrote:

> I couldn't help writing the below; I would love feedback on it, as I think I
> might turn it into a HelpTopic. In particular, it clearly wants a bit at the
> end about "where to file a bug," but I think the language about the mailing
> list below is okay; people with post bugs to the list regardless of how
> anyone feels about it:)
> WHAT'S IN A BUG
> One day, you will be Squeaking away happily, and something unexpected will
> happen. It could be something subtle, or it could be something really ugly:
> the VM might even crash. In any such case, you've found a bug.
> A dynamic programming environment like Squeak is a little different from a
> traditional shrink-wrapped application in that the bug you've found quite
> likely belongs to you. Before reporting an issue, it's a good idea to see if
> you can reproduce the problem in a fresh image of the same version. If you
> can't reproduce the issue in a fresh image, it's probable that you yourself
> have broken something. It's okay! Spend some time trying to figure out
> what's going wrong and why. Dig in and see what you can learn about the
> problem; anything you are able to learn this way will assist you in better
> communicating the problem if you do decide to ask someone in the community
> to help you. Just remember, the people in the community are just Squeakers
> like you, and are not employed or otherwise obligated to help you.
> On the other hand, if you can regularly reproduce the problem with a fresh
> image, you mat have found a bug in Squeak. If you do find a bug in Squeak,
> you should dig right in! Learn whatever you can about it. See if you can
> figure out how to fix it: there's nothing more satisfying than fixing a bug
> you've found yourself, except perhaps for sharing it with your friends on
> the mailing list. It's okay if you aren't able to fix the bug yourself, but
> before posting to the list, it's good to make sure you've checked the
> following boxes:
> - Write a general description of the problem.
> - Supply (as exactly as possible) the steps you use to reproduce the
> problem.
> - Explain what you expected to happen.
> - Explain what actually happened.
> - If the bug produces a crash, it's really helpful to include a stack trace.
> - If the bug has a visible component or effect, obtain a screenshot.
> - Note the version of the Squeak image that you are using.
> - Note version of the virtual machine you are running on.
> - Specify the operating system you are using.
> The above activities will help the community narrow down what might be going
> wrong. Above all, steps to reproduce the problem are the most critical
> component to debugging. Without a way to reproduce an issue, it's almost
> impossible to conduct a fruitful investigation of it.
> (INSERT CLOSING PARAGRAPH ABOUT WHERE AND HOW TO ACTUALLY FILE THE BUG)
> --
> Casey Ransberger
>
>
>
>