Changes between Version 8 and Version 9 of WorkingConventions


Ignore:
Timestamp:
Nov 13, 2006 3:58:03 PM (7 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WorkingConventions

    v8 v9  
    1313To submit patches to the developers, please use {{{darcs send}}}.  You don't need any special permission to do this.   
    1414 
    15 Broadly speaking there are two sorts of patches: bug fixes, and new features.  We treat them differently. 
     15Broadly speaking there are two sorts of patches: '''bug fixes''', and '''new features'''.  We treat them differently. 
     16 
     17We have separate guidelines for proposing changes to standard libraries; see [http://haskell.org/haskellwiki/Library_submissions Library Submissions]. 
    1618 
    1719=== Bug fixes === 
     
    2527 * 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. 
    2628 
    27 === Features === 
     29=== New features === 
    2830 
    29 We are more careful before committing new features. Here are some things to bear in mind: 
     31We welcome your involvement in making GHC able to do more.  That said, we think twice before committing new features. Here are some things to bear in mind: 
    3032  
    3133 * 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. 
    3234 
    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. 
    34  
    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. 
     35 * It may seem that running 'darcs apply' is practically free for us; you have done all the hard work.  But it isn't: 
     36   * It effectively commits us to maintaining it indefinitely, and worrying about its interactions with existing features 
     37   * We try hard 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. 
     38   * We have to do quality-control on your patch; we don't want to commit un-maintainable code... or even well-written code that we can't understand. 
     39   * If your patch breaks something else, we'll get blamed regardless.   
     40   * Subsequent new features have to take account of interactions with your feature. 
    3641 
    3742 * 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. 
    3843 
    39  * A new feature should come with 
     44 * A new feature should come with  
     45   * A commit message that (a) explains what the patch does, and (b) sketches how it works. 
    4046   * A patch to the user manual that documents it (part of the main source-code patch) 
    4147   * 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. 
     48 
     49 * Remember that GHC HQ is not heavily staffed!  It may take us a while to give your patch the attention it deserves. 
     50 
     51If you are working on a feature that you think you think is a candidate for including in GHC's main repository, you may want to talk to us while you are developing it.  We may well, for example, have advice about how to structure the change in a way that we're happy to incorporate in our code base. 
    4252 
    4353== Committing changes == 
     
    5363Do not forget to {{{darcs record}}} your changes first! 
    5464 
    55 == Guidelines for pushing patches == 
    56  
    57  * We have separate guidelines for proposing changes to standard libraries; see [http://haskell.org/haskellwiki/Library_submissions Library Submissions]. 
     65== Guidelines for people with commit permissions == 
    5866 
    5967 * Try to make small patches (i.e. work in consistent increments).