Patches

Version Control

• We use darcs for 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/war2 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 compiling a test in a non-standard way (like "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.