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
|