Changes between Version 7 and Version 8 of WorkingConventions

Nov 13, 2006 1:00:28 PM (11 years ago)



  • WorkingConventions

    v7 v8  
    1111== Submitting patches ==
    13 To submit patches to the developers, please use {{{darcs send}}}.  You don't need any special permission to do this.
     13To submit patches to the developers, please use {{{darcs send}}}.  You don't need any special permission to do this. 
     15Broadly speaking there are two sorts of patches: bug fixes, and new features.  We treat them differently.
     17=== Bug fixes ===
     19Bug fixes always extremely welcome.  GHC is so large, and is used in such diverse ways by so many people, that we really need your help in fixing bugs, especially those that show up in specialised situations.
     21 * In the darcs commit message, please say which Trac bug is being fixed
     23 * Comment your fix in the source code.  It is often helpful to give a small example code fragment that demonstrates the need for your fix.  This isn't always relevant; sometimes you are fixing a plain error, but often it's more subtle than that.
     25 * Please ensure that there is a test case in the regression-test suite that shows up the bug, and which is fixed by your patch.  This test case should be identified in the "Test Case" field of the Trac report.
     27=== Features ===
     29We are more careful before committing new features. Here are some things to bear in mind:
     31 * Your patch does not need to be incorporated in the main GHC repository to be useful.  The joy of Darcs is that you can send it to anyone, and they can use it quite independently.
     33 * Committing a patch that implements a new feature is not free for us. It effectively commits us to maintaining it indefinitely, and to worrying about its interactions with existing features, and (later) other new features.
     35 * Another consideration that we take seriously is trying to keep GHC's language design somewhat coherent.  GHC deliberately tries to host a variety of ideas, not all of which may be good, but we try to keep it under control.
     37 * New features should be switchable with their own flag, by default off.  We used to have just one flag `-fglasgow-exts` but nowadays we try to be much more selective.
     39 * A new feature should come with
     40   * A patch to the user manual that documents it (part of the main source-code patch)
     41   * A (separate) patch to the testsuite repository that gives a reasonable collection of tests for the new feature.  This has to be a separate patch, because the testsuite is a separate repository.
    1543== Committing changes ==