Version 8 (modified by benl, 4 years ago)

--

< Main

Making 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/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.