"SfR Fresh" - the SfR Freeware/Shareware Archive

Member "docs/tool_guide/contributing.html" of archive TestMaker.zip:

Caution: In this restricted "SfR Fresh" environment the current HTML page may not be correctly presentated and may have some non-functional links. Alternatively you can here view or download the uninterpreted source code. That can be also achieved for any archive member file by clicking within an archive contents listing on the first character of the file(path) respectively on the according byte size field.

Contributing To TOOL

TOOL is available under a license that allows you to have and modify the source as you see fit. It also does not require you to make any changes available to anyone else, including us. While you are not required to submit changes, we welcome them (and if you integrate your stuff with us, you get the advantage of having other people's improvements and fixes also without having to maintain a patch against the official version).

So, we encourage anyone who finds a bug to report it - we highly encourage anyone who fixes a bug to send the bug fix to us so that others can benefit too. As well, we will accept contributions, additional features, etc as long as they fit into the scope of the project and don't make any unnecessary breaks with backwards compatibility (sometimes it's inevitable - we know).

Below, we will outline the best way to get a patch included.

Source Code

Wether you send a new file or a patch against another file, please make every effort to follow the style of the code that is already there. It will make merging differences a lot easier and will make the code a lot neater if we don't have multiple styles (different programming languages have different conventions, so we will let the port maintainer elaborate more on how they would like the code to look).

Patches

Diffs are the easiest contributions for us to handle. Especially if the diff is against the latest CVS sources. Diffs should be smaller by default and generally one diff per bug-fix is preferable to many bug fixes in a single diff. When they are smaller it allows us to understand the intent and to evaluate the fix more easily.

Generally diffs should be agaisnt the whole tree recursively and with context turned on. It makes for larger patches, but they are easier to understand.

(examples using GNU diff, other tools may differ).

Single file:

diff -c some_file.c > somefile.patch

Whole directory (recursive):

diff -c -r tool/ my-branch-tool/

The recursive diff is preferable so that we can just patch from the top of the source tree.

Additional documentation, product downloads and updates are at www.PushToTest.com. While the TestMaker software is distributed under an open-source license, the documentation remains (c) 2006 PushToTest. All rights reserved.