Context Navigation

Making Patches

Version Control

For your first few patches, use darcs send to create a patch bundle, then email it to the disciple-cafe list.

After those have been accepted, get an account on code.haskell.org. We'll give you commit access to the head repo and you can darcs push subsequent patches directly.

Testing

Before sending or pushing patches do the following:

make cleanWar
make
bin/war test

This will clean out the libraries and test directory, rebuild the libraries, then run all the regression tests. If all the tests pass, then go ahead and send/push your patches.

If your patch adds a new feature then it should also include a test case for it. Submit the test case in the same patch as the code for the feature.

It's ok to push an "in progress" patch that cleans up existing code, or adds to it, without completing a feature. These patches don't need test cases, but the patch description should mention what it is working towards.

Handling Test Failures

We don't like having failures in the main test suite.

If the nightly buildbot encounters a failure when running a test in a non-standard way (like with "opt" or "prof") then someone should move that test into the test/Broken-skip directory and file a bug report.

Don't push other, non-fixing patches into a repo that has test failures.

Fixing Bugs

Most of the bugs in the issue tracker should have a failing test case in test/Broken-skip

When you fix a bug, mark it as resolved on the tracker then either move its test from test/Broken-skip into the main testsuite, or create a new test.

If you find it too hard to create a new test, then we might need to extend the war2 test driver.