|
|
# Testing Patches
|
|
|
|
|
|
|
|
|
Nowadays there are many people working on GHC, which is a Good Thing, but it does mean that many people are inconvenienced if a patch is pushed which makes the HEAD unbuildable. To try to reduce the number of times this happens, we now have a stricter policy for testing patches before committing them.
|
|
|
|
|
|
|
|
|
In order to test your patches:
|
|
|
|
|
|
- Get a repository containing the latest HEAD, the patches you want to push, and no other patches or unrecorded changes. Depending on what you are doing, your working repository might be appropriate; otherwise you might prefer to keep a separate repository just for patch testing.
|
|
|
- Run the validate script in the root of the tree. This will do a "quick" build and then run the testsuite in "fast" mode. Do not push if any of the tests give unexpected results!
|
|
|
- Depending on the nature of the changes, more testing might be sensible. e.g. if possible, build system changes should be tested on Linux, Mac OS X and Windows machines.
|
|
|
|
|
|
|
|
|
The validate script should take around 20mins on a fast, dual core machine.
|
|
|
|
|
|
|
|
|
Assuming all is well, go ahead and commit your changes! If you have commit access then just push as normal. If not, use "darcs send --edit-description" and add a note to say what testing you have done, and on which operating system/architecture. |