Work in progress
As more people are using software we have developed (and we're still developing), I'm getting more and more emails like:
Hey, I've tried XYZ and it doesn't work. Do you know where/what is the problem?
and sometimes:
Can you fix it?
Time to time, there is an screenshot of debugger attached... Obviously, answers are: No. and Maybe. I need much more information in order to (hopefuly) fix the problem than just It doesn't work :-)
In this post, I'm going to summarize how to report a bug or any other issue properly. Sending a proper report makes your chance that I'll look at your problem and (possibly) fix it significantly higher. So:
_
Writing…
The most important thing is to ""provide enough information to reproduce the bug"". That means:
- Provide information about your system, i.e., operating system and its version, whether you use a 32bit/64bit OS, what exactly version of Smalltalk/X you use - that's important. The system is evolving quite fast, we are adding new features almost every day. Ideally, provide a link to an installation archive of version you're using or a Jenkins* build number of build you're using.
- Provide step-by-step description how to reproduce the bug. Start from the very beginning - run the environment, then do this, evaluate that, etc. Really important!
- Describe what happens and what you expect to happen. There were (and there will be, for sure) number of bugs that depends on timing, memory layout and things like that so the bug may not appear on my box.
- If the result of the bug is that a debugger appears, attach a walk-back text. To get one, in debugger window's menu select Context / Copy WalkBack Text. A walk-back text is then copied to the system clipboard, so you may paste it into a file using your favorite text editor. A screen-shot of an debugger is much less usable than the walk-back text.
- Ideally, provide a test case in form of code, preferably as sUnit test. If you're an experienced programmer, writing one should be a piece of cake. If you're programmer but not experienced, give a try - at least this is a good exercise :-) If you don't know anything about programming, then you can't write a test case :-) I'm OK with this, no worry.
Submitting…
Well, now we know how to write an report, but how to send it. Email? Better is to put it into a bug reporting system - just click to New Ticket - note that you have to login first using your Google account.
Alternative (less-preferred) is to send an email to the mailing list: stx-jv@…
After a submission…
Submit a bug is not the end of the story, even for the reporter. You may be asked to test a new version and say whether it works or not. You should do it. You may fill in your email in trac, in that you will be sent an email when somebody comments or changes the bug report you submitted.
Summary
Doing a proper bug report saves my time and, therefore, increases your chance that I'll work or it and fix it for you. For an example look at famous bug #9
