[http://trac.haskell.org/ddc/wiki < Main]

= Making Patches =

== Version Control ==
 * We use [http://www.darcs.net 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 cleanLibrary
  make cleanWar
  make war
}}}

 This will clean out the libraries and test directory, rebuild the libraries, then run all the regression tests in the normal (non-optimised) way. This is the ''minimal'' required testing before pushing patches into the head branch. If you've made a deep change to something like the type inferencer or core transforms then you should run all the tests in all possible ways:
{{{
  make cleanLibrary
  make cleanWar
  make totalwar
}}}

 If you've added a lot of files to the version control system (`darcs add`) and might have forgot some, or you just want to be extra sure you're not going to break anything, then it's best to use a separate testing repo. First make a new version of the head repo (maybe called `ddc-head-test`). Record your patches in the original repo, push them into the testing repo, then in that repo do:
{{{
  make cleantotal
}}}

 Using this method has the additional advantage that in the testing repo you can leave the `BUILDFLAVOUR` set to `distro`. This means that the compiler itself will be built with optimisations turned on, and the tests will go through a lot faster.

 * 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") 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 {{{war}}} test driver.