|Version 8 (modified by benl, 6 years ago)|
- 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.
- 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.
- 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.