How to submit bugs, fixes and enhancements

Doug Way dway at mat.net
Mon Apr 24 23:28:22 UTC 2000


I thought this was useful info, so I copied it to the Swiki at
http://minnow.cc.gatech.edu/squeak/1385 , adding a few appropriate links
to it.

- Doug Way
  EAI/Transom Technologies, Ann Arbor, MI
  http://www.transom.com
  dway at mat.net, @eai.com


On Mon, 24 Apr 2000, Stefan Matthias Aust wrote:

> Hi, happy Easter!
> 
> 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 choose a meanful 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.
> 
> 
> Another 30 updates for 2.8a should be available in the next few days.
> 
> These are mostly from April and March submissions.  If YOU provided a fix 
> or an enhancement meant for the base image but never saw it as an official 
> update, drop me a short note as we probably had overlooked it.  You can see 
> the pending list of updates at www.3plu4.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 :-)
> 
> 
> bye
> --
> Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
> 
> 





More information about the Squeak-dev mailing list