Stefan Matthias Aust's comments on bug/fix reporting
Last updated at 1:08 pm UTC on 16 January 2006
See Reporting Bugs and Fixes for the latest.
Some of the information below is out of date, but it is still useful. Now, a group of people (Managing BFAV Posts) is reviewing/collecting fixes and enhancements, using a Harvesting Process.
On Monday, April 24th, 2000, Stefan Matthias Aust wrote:
As you might know already, I am helping to collect bug fixes and enhancements for the Squeak base image. I'm using the mailing list as main source. To speed up this process, you could help me by following these recommendations:
- ALWAYS mark bug fixes by adding [FIX] to the subject line and enhancements for the base images by adding [ENH]. If you just noticed a bug but cannot provide a fix, please use [BUG]. As I've still some 1000 messages to catch up, I must rely on mail filters.
- ALWAYS use the change set format (.cs) when publishing code. Otherwise I need to create one from your source which not only takes more time but also makes me the author of the change. Please also add a short Preamble (from the change sorter) which describes what the change set does.
Please choose a meaningful title, add yourself as author and add a problem description, how to reproduce it and what you fixed. This helps me to understand the problem and to check for conflicts - especially if the change set provided was done for an older version of Squeak.
- Please add change sets ALWAYS as binary attachment. Make sure that your mail tool doesn't put the source into the body of the mail and/or changes tabs into spaces or fiddles around with the line ending convention. Squeak's .cs files are BINARIES.
If you use EUDORA for example, you can switch on "text as attachment" which should do the right thing. It's really annoying to switch back the line ending stuff to Squeak format and replace spaces with tabs again.
If in doubt, use .gz compression to assure binary mode. Also use .gz compression if the change set is larger than a few KB. If you think, your change is too large for the list (let's say more than 10 KB), still send it directly to me if smaller than 100 KB. I prefer this over getting the change set from the web myself.
You can see an old historic list of updates at http://www.3plus4.de/squeak.
We're always looking for more submissions, so if you think about helping, here's my hit list of what kind of changes I'd like to see. I'm kind of extreme (as in eXtreme programming) and "if it ain't broken, don't fix it" is NO rule here.
- bug fixes - broken things need to be fixed ASAP. But keep in mind how the bug impacts the rest of the system. If refactoring is needed, do this also.
- refactorings - if you can provide a better, shorter, better communicating alternative to existing source code, please send it in. If you see bad code, rewrite it. If you see missing commments, add them.
- speed improvements - if you detect a major performance problem, please provide your optimizations. If it makes the code even simpler and better communicating, great.
- usability improvements - if a small enhancement can greately improve the usability of the tools, add it. Keep in mind refactorings.
- other enhancements - if I like it, I recommend to add it :-)
