Source Code

Source code repository

All development goes into a Subversion repository hosted by Sourceforge.net.

Accessing the repository

You can browse the repository or use your favorite subversion client (for windows users your best bet will be TortoiseSVN) to checkout the latest source code (https://nplot.svn.sourceforge.net/svnroot/nplot/trunk for trunk) and start working on it.

Then if you don't have commit access or need approval for your commit, do a diff with subversion's diff command and send it to development mailing list or attach it to the tracker item it belongs.

All contributed code must follow the project's coding guidelines and must avoid changing anything that is not needed for the purpose of the change done. That includes white space/indentation changes, classes/methods/properties/fields names' changes, ... or anything that makes harder to review commits.

Targets

The NPlot VS project files are currently targeting the .Net Framework version 1.1. In order to open this project in Visual Studio 2005 one must first install MSBee. MSBee is a small tool from Microsoft that allows Visual Studio 2005 projects to target the v1.1 framework.

We also provide MonoDevelop solution files, NAnt build file and a Makefile. VS 2005 project files are also compatible with SharpDevelop, so you have a broad range of choices to develop NPlot.

trunk

Our development cycle will aim at a reasonably stable trunk so all complex developments will go into feature branches.

In order to keep trunk as stable as possible, direct commit there is forbidden for all developers and every trunk commit must be approved by a project admin.

Changes that will qualify to go directly into trunk are bug fixes, externally contributed patches that don't need extra work, and in general anything trivial enough to not need a dedicated branch. In general new unit tests will be required for trunk commits that cover the new code or test the bug fixed.

Any trunk commit must be free of regressions, so all unit tests must pass.

Branches

Any feature or milestone that can't be worked on a single commit must go into it's own dedicated branch. Branch creation must be approved by an admin and must have a meaningful name and a log messages that explains the scope and purpose of the branch.

Branch owners will be responsible of their branches and how development is organized there. Any number of developers can commit to a branch if branch owner decides so.

Once a branch has met its goals, branch owner will ask for merge to a project admin.

Log messages

Log messages for every commit must be meaningful and verbose enough to understand what has changed and why. Log message should consist of a general introduction that describes the purpose of the commit followed by lines describing particular changes that went into each file and method or property.

Commits that refer to a tracker item (bug or submitted patch) must say so as [SF bug #] or [SF patch #]. You must also credit the author of contributed code in the log message, and state whether the whole commit is contributed or it needed some work.

Commits that must be approved by and admin, must have a last line that reads 'Signed off by: <admin sf.net username>' (or several if more than one admin has reviewed and approved the commit).

Log example:

Fixed [SF bug 12345]
* [src/filename.cs] MethodName: parameter x was being used ...
Signed off by: projectadmin1

Commit access

Once you have contributed a number of patches and been around for a while, you'll be able to gain commit access to the project.

Rules that'll drive this process aren't specified yet.