RTEMS Bug Reporting

Our preferred way of receiving bug reports is via the ​RTEMS Trac ticket system. If you have patches not specifically related to bugs or existing tickets, we prefer to use the Developer's Mailing List.

In general, if you have a bug to submit follow the instructions:

1. Sign in to the RTEMS Trac website using the ​Trac Login.
2. Click in ​View Tickets (upper right corner of the screen).
3. Search for a similar ticket about the bug (to avoid duplicates).
4. If you haven't found a similar ticket, create a ​New Ticket and:
   1. Add a useful single line summary.
   2. Set the Type field to defect for a bug. Note infra is used to report issues with the RTEMS servers at OSUOSL.
   3. Set the Version field. If it is with the current git master branch use the next version
   4. Set the Component field and leave as General if you are not sure.
   5. 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.
   6. Click Create Ticket when you are happy you have all the details you can provide.

Managing Bugs

This section contains information mostly intended for RTEMS contributors. But if you submit a bug report, it is very important for you to submit a reproducible test case. These submitted test cases end up being added to the test suite to prevent future regressions.

If you find a bug, but you are not fixing it (yet):

• Create a (minimal) test-case.
• Add the test-case to our test-suite, documenting it as a current failure unless the bug is a regression.
• Add a bug report referencing the test-case to Trac.

If you want to provide additional information in the bug tracking system about a reported bug:

• If the bug has been tracked down to a specific area or routine in RTEMS, please provide information about its location.
• Minimize the test case.
• Try the test case with earlier and later versions of RTEMS to determine which versions it affects and whether it is a regression. If it is a regression, identify the patch that introduced it.

If you fix a bug for which there is already a Trac ticket:

• Remove the failure notation on the test-case.
• Attach your fix and test case to the Trac ticket.
• Close the ticket by adding fixes #<ticket numer> to the commit message.

If you find a bug, and you are fixing it right then:

• Create a (minimal) test-case.
• Add the test-case to our test-suite, documenting it as known to work.
• Check in your fixes.

Maintainer's View of Fields

As a RTEMS-specific convention, we will attach a special meaning to some fields. The State field should be used in the following way:

• open - The PR has been filed and the responsible person(s) notified.
• 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.
• 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.
• 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.
• 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.

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.

Procedures and Policies

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.

Regressions should be explicitly marked as such. The synopsis line should read

    [<branches-to-fix> regression] <rest-of-synopsis> 

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".

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).

• If the response is "works now", close the report,
• if the response is "still broken", change the state to "open", and
• if no response arrives, close the PR after three months.