Changes between Version 9 and Version 10 of Developer/Bug_Reporting


Ignore:
Timestamp:
Mar 22, 2015, 3:19:27 AM (5 years ago)
Author:
Chris Johns
Comment:

Add ticket states and git commit keywords.

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Bug_Reporting

    v9 v10  
    1717  a. Describe the bug or issue in the `Description` field with any details useful to the RTEMS maintainers such as host machine, build of tools, output traces, plus if you have any local modification and detailed instructions in order to reproduce the bug. The `WikiFormatting` is useful in formatting the information you provide and it does help the readability of the information you provide.
    1818  a. Click `Create Ticket` when you are happy you have all the details you can provide.
     19
     20The [wiki:TracWorkflow Trac Ticket Workflow] details the workflow for RTEMS Tickets.
    1921
    2022= Managing Bugs =
     
    4547* Check in your fixes.
    4648
    47 = Maintainer's View of Fields =
     49The state of a ticket is:
    4850
    49 As a RTEMS-specific convention, we will attach a special meaning to some fields. The State field should be used in the following way:
     51   '''open''':: The ticket has been filed and the responsible person(s) notified.
     52  '''accepted''':: The assigned maintainer has verified that this is indeed a bug in RTEMS. Every once in a while, old reports will need to be rechecked, to find out whether the bug still exists. At that time, an indication should be left in the report who tested the bug and when.
    5053
    51   *  '''open''' - The PR has been filed and the responsible person(s) notified.
    52   *  '''analyzed''' - A maintainer has verified that this is indeed a bug in RTEMS. Every once in a while, old reports will need to be rechecked, to find out whether the bug still exists. At that time, an indication should be left in the report who tested the bug and when.
    53   *  '''feedback''' - The submitter was asked for further information, or asked to try out a patch. The PR remains in that state until the submitter responds.
    54   *  '''working''' - Someone is actively working on fixing the problem and has determined that it may take a while to fix. The intention of this state is to make sure that if someone is working on the problem, that everyone knows it so they can better coordinate efforts.
    55   *  '''suspended''' - Work on the problem has been postponed. This happens if a timely solution is not possible or is not cost-effective at the present time. The PR continues to exist, though a solution is not being actively sought. If the problem cannot be solved at all, it should be closed rather than suspended.
     54The `resolve` action has the following:
    5655
    57 In addition, the high priority is reserved to maintainers in RTEMS, indicating that a certain problem must be solved before the next version of RTEMS is released.
     56  '''fixed''':: The bug has been fixed.
     57  '''invalid''':: The bug report is not valid and nothing further will be done.
     58  '''wontfix''':: The bug will not be fixed.
     59  '''duplicate'''::The ticket is a duplicate of any other ticket and that ticket should be referenced in future.
     60  '''worksforme''':: The bug could not be repeated and there is not more the maintainer can do.
    5861
    59 = Procedures and Policies =
     62If a bug has been closed and you think there has been a mistake please reopen the ticket and add suitable comments to explain the reason for reopening the ticket.
    6063
     64The high priority is reserved to maintainers in RTEMS, indicating that a certain problem must be solved before the next version of RTEMS is released.
    6165
    62 Bugs that are in state "feedback" because they lack information that is necessary for reproducing the problem can be closed if no response was received for three months.
     66Tickets can be automatically updated using a git commit message. If the commit contains `fixes #12345` the ticket ''12345'' will be closed and the commit message used a comment in the ticket. The valid keywords are:
    6367
    64 Regressions should be explicitly marked as such. The synopsis line should read
     68  '''Close a ticket''':: `close` `closed` `closes` `fix` `fixed` `fixes` `Close` `Closes` `Closed` `Fix` `Fixed` `Fixes`
    6569
    66 {{{
    67     [<branches-to-fix> regression] <rest-of-synopsis>
    68 }}}
    69 
    70 where <branches-to-fix> is the list of maintained branches (separated by slashes) that need fixing. A regression should start with priority "high" to bring it to attention. It may be downgraded later if a defect is not important enough to justify "high priority".
    71 
    72 Bugs that refer to older releases or snapshots/CVS versions should be put into state "feedback", asking the reporter whether they can still reproduce the problem and to report their findings in any case (whether positive or negative).
    73 
    74  *  If the response is "works now", close the report,
    75  *  if the response is "still broken", change the state to "open", and
    76  *  if no response arrives, close the PR after three months.
     70  '''Update a ticket''':: `addresses` `references` `refs` `see` `address` `update` `updates` `Refs` `See` `Address` `Update` `Updates`