From 9f2119e14bb8e195eaa4c9c869dfd87c6d8904d7 Mon Sep 17 00:00:00 2001 From: Christoph Thiede <38782922+LinqLover@users.noreply.github.com> Date: Wed, 16 Jun 2021 19:53:05 +0200 Subject: [PATCH 1/3] Add best practice of referencing to development process --- _pages/development_process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_pages/development_process.md b/_pages/development_process.md index df8ddb6..bba5185 100644 --- a/_pages/development_process.md +++ b/_pages/development_process.md @@ -89,7 +89,7 @@ Here are some useful guidelines: * **You break it, you fix it.** If you change something, you are generally expected to take care of problems caused by this change. Though there are exceptions. If in doubt, please ask. -* **Do good and talk about it.** When you are done with whatever you have been working on, let people know about it. It can be as short as a note to Squeak-dev saying “I have fixed the long standing bug with *xyz.* Please update and enjoy.” +* **Do good and talk about it.** When you are done with whatever you have been working on, let people know about it. It can be as short as a note to Squeak-dev saying “I have fixed the long standing bug with *xyz.* Please update and enjoy.” Large numbers of interconnected patches and discussions can be hard to survey for others. Whenever possible, include references to related Monticello versions or threads on the mailing list (which are permalinkable via the [nabble forum](http://forum.world.st/Squeak-Dev-f45488.html) or the [pipermail archives](http://lists.squeakfoundation.org/pipermail/squeak-dev/)) in the summary of your work. In particular, try to document when you move a version to the treated inbox. * **Unit Testing.** Unit tests are an essential part of maintaining the reliability of our releases. New unit tests are always welcome. Keep in mind that a unit test should take as little time to run as possible. Maintaining the reliability of Squeak is always easier when all tests pass: If you break something, the appearance of a new failure or error is immediately obvious and the cause is more easily found. To that end fixes for failures or errors are extremely valuable. Also, please avoid submitting changes that cause failures or errors themselves. From fee78de9b5b51b6dae6b0bce0cf0a56df2c64f6a Mon Sep 17 00:00:00 2001 From: Christoph Thiede Date: Tue, 27 Sep 2022 10:00:02 +0000 Subject: [PATCH 2/3] development process: Add link to in-image tutorial --- _pages/development_process.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/_pages/development_process.md b/_pages/development_process.md index bba5185..a1f2567 100644 --- a/_pages/development_process.md +++ b/_pages/development_process.md @@ -68,6 +68,11 @@ In detail, the process for classes or methods works as following: 3. Maybe rewrite the deprecated method to use the new implementation, if there is one. 4. Add `self deprecated: 'Use this or that instead.'.` at the beginning of the deprecated method to guide foreign application code through the migration. +## Further References + +There is also a tutorial integrated in the image that describes the process and the tooling for submitting a contribution in-depth. +You can find it under the docking bar in the help menu under "How to Contribute". +
From becd107eb2730ef0dc6467fa71d8aa923581dbbd Mon Sep 17 00:00:00 2001 From: Christoph Thiede Date: Tue, 27 Sep 2022 10:04:20 +0000 Subject: [PATCH 3/3] development process: Update "do good and talk about it" again - do not refer to "pretty dead" nabble - do not advise to mention every treatment, since treated versions are now announced on packages@lists.squeakfoundation.org --- _pages/development_process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_pages/development_process.md b/_pages/development_process.md index d4cc944..616f65a 100644 --- a/_pages/development_process.md +++ b/_pages/development_process.md @@ -94,7 +94,7 @@ Here are some useful guidelines: * **You break it, you fix it.** If you change something, you are generally expected to take care of problems caused by this change. Though there are exceptions. If in doubt, please ask. -* **Do good and talk about it.** When you are done with whatever you have been working on, let people know about it. It can be as short as a note to Squeak-dev saying “I have fixed the long standing bug with *xyz.* Please update and enjoy.” Large numbers of interconnected patches and discussions can be hard to survey for others. Whenever possible, include references to related Monticello versions or threads on the mailing list (which are permalinkable via the [nabble forum](http://forum.world.st/Squeak-Dev-f45488.html) or the [pipermail archives](http://lists.squeakfoundation.org/pipermail/squeak-dev/)) in the summary of your work. In particular, try to document when you move a version to the treated inbox. +* **Do good and talk about it.** When you are done with whatever you have been working on, let people know about it. It can be as short as a note to Squeak-dev, or a comment in the issue tracker, saying “I have fixed the long standing bug with *xyz.* Please update and enjoy.” Large numbers of interconnected patches and discussions can be hard to survey for others. Whenever possible, include references to related Monticello versions or threads on the mailing list (which are permalinkable via the [pipermail archives](http://lists.squeakfoundation.org/pipermail/squeak-dev/)) in the summary of your work. * **Unit Testing.** Unit tests are an essential part of maintaining the reliability of our releases. New unit tests are always welcome. Keep in mind that a unit test should take as little time to run as possible. Maintaining the reliability of Squeak is always easier when all tests pass: If you break something, the appearance of a new failure or error is immediately obvious and the cause is more easily found. To that end fixes for failures or errors are extremely valuable. Also, please avoid submitting changes that cause failures or errors themselves.