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
|