Version 28 (modified by benl, 6 years ago) (diff)


Making Patches

Version Control

  • For your first few patches, make a fork on GitHub and send a pull request.
  • After those have been accepted, we'll make you a direct committer to the GitHub project.
  • The mirror is automatically updated from the GitHub project once per day, but if you do lots of DDC hacking then we'll make you a direct account on the mirror as well.
  • The mirror is on the machine, and * are aliases for it.
  • The buildbot and trac servers are also on

Mirror Push

  • For people with direct access to the mirror, use the following git commands so that your commits go to both repositories.
    # Make a new remote named 'all' with GitHub as the default.
    git remote add all \
    # Add a second URL for the mirror to the 'all' remote.
    git remote set-url --add all \
    # To see if the setup worked use:
    git remote show all
    # To set 'all' to be the default upstream for push, use:
    git push -u all
    # Otherwise, you must explicitly select all for each push:
    git push all


  • Before sending or pushing patches do the following:
    make clean
    make war

This will do a fresh rebuild, then run all the regression tests for the new (non-alpha) compiler. 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 clean
make total

If you've added a lot of files to the version control system 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 clean
make total

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 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 trac 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.