Changes between Version 58 and Version 59 of WorkingConventions


Ignore:
Timestamp:
Sep 20, 2010 9:53:40 AM (4 years ago)
Author:
simonmar
Comment:

tidy up the page, moving most content into subpages with clear links

Legend:

Unmodified
Added
Removed
Modified
  • WorkingConventions

    v58 v59  
    1313 * [http://haskell.org/haskellwiki/Library_submissions How to propose a change to the libraries] 
    1414 
    15 == Coding conventions == 
     15== Conventions == 
    1616 
    17 When you are editing GHC's source code, please follow our coding guidelines: 
     17 * '''Using Darcs''': Our conventions and some useful tips for using darcs are here: [wiki:WorkingConventions/Darcs]. 
    1818 
    19  * [wiki:Commentary/CodingStyle Coding style in the compiler] 
    20  * [wiki:Commentary/Rts/Conventions Coding style in the runtime system] 
     19 * '''Using the Bug Tracker''': see [wiki:WorkingConventions/BugTracker] 
    2120 
    22 == Validating patches and the test suite == 
     21 * '''Coding style''': When you are editing GHC's source code, please follow our coding guidelines: 
     22   * [wiki:Commentary/CodingStyle Coding style in the compiler] 
     23   * [wiki:Commentary/Rts/Conventions Coding style in the runtime system] 
    2324 
    24 Before you commit a patch you want to be reasonably sure you haven't broken anything.  So before you commit, you must '''validate''' your changes, using the '''regression test suite''': 
    25  * The policy on validating patches, and how to perform validation, is at: [wiki:TestingPatches]. 
    26  * Details about the regression test suite, and how to use it are at: [wiki:Building/RunningTests] 
     25 * '''Testing''': all patches that go into GHC must first pass ''validation'', which ensures that a basic build works and the ''regression test suite'' passes. 
     26   * The policy on validating patches, and how to perform validation, is at: [wiki:TestingPatches]. 
     27   * Details about the regression test suite, and how to use it are at: [wiki:Building/RunningTests] 
    2728 
    28 == Using Darcs == 
    29  
    30 Our conventions and some useful tips for using darcs are here: [wiki:WorkingConventions/Darcs]. 
    31  
    32 ------------------------------- 
    33 == The Bug Tracker == 
    34  
    35 We organise our work (both bug fixing and feature requests) using the Trac bug tracker.   There are links to the bug tracker in the sidebar under "View tickets" and "Create ticket". See also: 
    36  * [wiki:ReportABug the bug reporting guidelines] 
    37  * [wiki:WorkingConventions/FixingBugs How to fix a bug in GHC] 
    38  
    39  
    40 === Type and status === 
    41  
    42 Every ticket has a '''status''' and a '''type''', which appear in the title of the ticket.  Thus "Ticket #2762 (new bug)" means status=new, and type=bug.  Here's what they mean: 
    43  
    44  * '''Type''' is one of `bug`, `feature request`, `task`, or `proposal`. The `proposal` type is only for [http://www.haskell.org/haskellwiki/Library_submissions library submission] proposals. 
    45  
    46  * '''Status''' says what state the ticket is in.  It is one of these: 
    47    * '''New''' is for open tickets that need to be triaged or fixed. 
    48    * '''Infoneeded''' means that the ticket is stalled awaiting information from the submitter (or anyone else). 
    49    * '''Closed''' means what it says. 
    50    * '''Merge''' means that a fix has been committed to the HEAD, but should be propagated to the current release branch. 
    51    * '''Patch''' means that the ticket includes a patch for review.  We love patches!  So we try hard to review patches promptly and either commit them, or start a conversation with the author. 
    52 The intention is that tickets do not live in the Merge or Patch state for long. 
    53  
    54 You change the status of a ticket using the Action box at the bottom.  Particularly, if you add a patch for a ticket, click the "please review" action at the bottom to change its status to "Patch". 
    55  
    56 === Other Trac ticket fields === 
    57  
    58 Each ticket has a bunch of other fields too: 
    59  
    60  * '''Milestone''': this field is for the GHC development team to indicate by when we intend to fix the bug.  We have a milestone for each planned release (e.g. "6.12.3"), and three special milestones: 
    61    * An empty milestone field means the bug has not been triaged yet.  We don't yet know if the 
    62      ticket is a real, unique, issue.  Once this has been established, the ticket will be given 
    63      a milestone. 
    64    * '''Not GHC''' is for tickets that are not tied to a GHC release. 
    65    * '''_|_''' is for tickets that have been triaged, but we don't plan to fix them for a particular 
    66      release.  This might be because the bug is low priority, or is simply too hard to fix right now. 
    67  
    68  * '''Severity''': this is set by the submitter of the ticket, and indicates how important the issue is to 
    69    them, i.e. is it preventing them from doing something altogether, or just a minor annoyance.  The 
    70    severity might be reduced if we discover a workaround. 
    71  
    72  * '''Priority''': this field is for the GHC development team to help us prioritise what we work on. On a release milestone, the highest priority tickets are blockers for that release, and the high priority tickets are those that we also plan to fix before releasing. We will also try to fix as many of the normal and lower priority tickets as possible. 
    73  
    74  * '''Test Case''': fill in this field with the name of the test in the test suite.  Typically every bug 
    75    closed should have an appropriate test case added to the test suite. 
    76  
    77  * '''cc''': we pay more attention to tickets with a long cc list, so add yourself to the cc list if you care about the ticket.  Better still, add a comment to explain why you care. 
    78  
    79  * '''Owned by''' says who is committed to taking the ticket forward.  We typically leave this field blank until we actively start working on it, lest others feel unable to to work on a ticket because it is apparently owned, even though nothing is happening. 
    80  
    81 === Releases === 
    82 When a release is made, any open tickets on that release's milestone will be moved to the next release's milestone. However, if they are more than 1 major release old (e.g. opened on the 6.10 branch, and about to be moved to the 6.14.1 milestone), and there is not a reason to keep them in the release milestone (e.g. a patch attached for review, or significant support in the CC field), then they will be moved to the `_|_` milestone instead. 
    83  
    84 === Workflow === 
    85 The ticket workflow is illustrated in the following image. Most tickets will start in state "new" and, once fixed, possibly go via state "merge" if they are suitable for merging to the stable branch, before moving to state "closed". They may also go via state "infoneeded" if more information is needed from the submitter, or "patch" if a patch that needs review has been attached to the ticket. 
    86  
    87 [[Image(workflow.png)]]