Changes between Version 20 and Version 21 of WorkingConventions

May 30, 2007 9:42:09 AM (10 years ago)

add section on patch naming


  • WorkingConventions

    v20 v21  
    4848 * A new feature should come with
    49    * A '''commit message''' that (a) explains what the patch does, and (b) sketches how it works.
     49   * A '''patch name''' and '''description''' that (a) explains what the patch does, and (b) sketches how it works.  See "Patch naming" below for conventions concerning the patch name.
    5050   * A '''patch to the user manual''' that documents it (part of the main source-code patch)
    5151   * 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.
    6060If 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.
     62== Patch naming ==
     64We have a simple naming convention for certain kinds of patches:
     66 * If your patch fixes breakage in the build, then begin the patch name with `"FIX BUILD"`. e.g.
     68  FIX BUILD Use the right find on Windows systems; fixes bindist creation
     70  The point here is that if someone pulls GHC from darcs and experiences a build failure, they can try
     71  `darcs pull -a -p "FIX BUILD"` in order to grab patches that fix it, without grabbing anything else
     72  that might introduce further breakage.
     74 * If your patch fixes a bug, then begin the patch name with `"FIX #NNNN"`, where `NNNN` is the ticket
     75   number. e.g.
     77  FIX #767 (withMVar family have a bug)
    6280== Committing changes ==