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 ?
Bye
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 ?
If somebody on this list could give an "official" and comprehensive answer, I believe it would be a good thing to put on the web site (which I could organise).
There was a post by Stef some time ago, but I can't find it.
Mikevdg.
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 ?
Bye
On 1 juil. 06, at 13:27, Damien Cassou wrote:
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
What do you mean ?
I mean that if you have lot of clients using an interface this is complex since even if the refactoring is simple we should not neglect the cost of the client's update. When you are the sole user of your code refactoring is cool, now we should take into account others. There is a tension between these two considerations ;) Stef
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 isdifficult 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.
Bug reports and small code contributions can be either added to the *Mantis* bug reporting system, or to the *Squeak mailing list*.
You should replace 'or the Squeak mailing list' by 'and the squeak mailing list' in my opinion.
- Ensure that your code is submitted to the relevant *Team*.
Replace *Team* by *Category* because this is what Mantis ask for.
- [What's deprecation???]
Deprecation means that a method still exist in the image because some code use it, but new code must not use it. Deprecated methods may be removed sooner or later. Use #deprecated: to signal that a method should not be sent anymore.
Bug reports should be submitted to the *Mantis bug reported system*.
Add the web address: http://bugs.impara.de
Bye
Damien Cassou wrote:
Bug reports and small code contributions can be either added to the *Mantis* bug reporting system, or to the *Squeak mailing list*.
You should replace 'or the Squeak mailing list' by 'and the squeak mailing list' in my opinion.
...that's a subjective opinion.
I think I'll add your version to the website and wait for disagreement :-).
- Ensure that your code is submitted to the relevant *Team*.
Replace *Team* by *Category* because this is what Mantis ask for.
Umm... I meant directly to that team's mailing list. I think all of the "how to use Mantis" should be in its own section. Hmm...
Bug reports should be submitted to the *Mantis bug reported system*.
Add the web address: http://bugs.impara.de
All of the *items in stars* would be replaced with relevant URLs when I get around to writing this up.
Thanks for the comments! Much appreciated.
Michael.
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 isdifficult 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
squeak-dev@lists.squeakfoundation.org
-
Damien Cassou -
karl -
Michael van der Gulik -
stéphane ducasse