Refactoring squeak (version for squeak.org)

karl karl.ramberg at chello.se
Sun Jul 2 10:13:21 UTC 2006


Michael van der Gulik skrev:
> Comments below. This is also BCC'ed to the web team.
>
> stéphane ducasse wrote:
>> If you want to increase the chance that your fixes get attention 
>> here  are some tricks.
>>
>>     - write tests to show that you do not break the system
>>     - do not refactor for the sake of it
>>     - use deprecation to support users of the old code
>>     - ask people for feedback and review
>>     - and yes having a better system is important (even if this is  
>> difficult and may break some existing code)
>>
>> Stef
>>
>> On 30 juin 06, at 10:34, Damien Cassou wrote:
>>
>>> Hi,
>>>
>>> sometimes when I dive into Squeak source code, I would like to  
>>> refactor some piece of code that can be enhanced. Does someone care  
>>> to have better source code in Squeak ? Where is the best place to  
>>> post the enhancements ? To post new tests ? Often, it will be just  
>>> one line or two, do I need to write bug reports in mantis ? Will  
>>> somebody have a look at this ?
>
> Would authoritive-sounding people comment on the following as a page 
> on the official Squeak website:
>
> Contributing (subcategory under "Community").
> ----------------------
>
>
> Contributing small amounts of code
> -------------------------------------
>
> Bug reports and small code contributions can be either added to the 
> *Mantis* bug reporting system, or to the *Squeak mailing list*. Squeak 
> developers (which, after a contribution, will include you!) use the 
> Mantis system to keep track of small changes and to eventually merge 
> them into Squeak.
>
> Remember that Squeak is developed by volunteers so that your 
> contribution of code or a bug report may or may not get attention. In 
> order to increase the chances that your bug or code contribution 
> receives attention, try the following:
>
> * Ensure that your code is submitted to the relevant *Team*. Each team 
> has their own preferences as to the preferred format of that code 
> (Monticello / Change sets).
>
> * Write tests that verify that your code does not break the current 
> Squeak system.
>
> * Contribute changes that keep as much backwards compatibility as 
> possible.
>
> * [What's deprecation???]
>
>
> Contributing large amounts of code
> ------------------------------------------
>
> If you want to contribute a significant amount of code, your project 
> can be published using *SqueakMap*. If your code is of a different 
> nature, as on the *Squeak mailing list*.
>
> You can start your own mailing list for your project using the *Squeak 
> foundation mailing lists server*.
>
> *SqueakSource* can be used to store a repository of your code. [and a 
> wiki?].
>
>
> Filing bug reports
> ---------------------
>
> Bug reports should be submitted to the *Mantis bug reported system*.
>
> In order to aid others in fixing your bug, try the following:
>
> * Spend at least a non-trivial amount of time tracking down the bug 
> yourself.
>
> * In your bug report, include the nature of the bug and good 
> instructions on how to reproduce that bug.
>
> * If you have written a test to reproduce the buggy behaviour, include 
> that as an attachment to your bug report.
>
>
>
Looks good, Michael.
One remark, before adding a bug report one should first search mantis to 
see if the bug is
already reported.
Karl



More information about the Squeak-dev mailing list