Changes between Version 15 and Version 16 of Developer/Bug_Reporting

Timestamp:

11/12/18 19:20:20 (6 years ago)

Author:

a-bhatt

Comment:

minor grammatical errors

Developer/Bug_Reporting

@@ -14 +14 @@
  *  The options given when RTEMS was configured/built
  *  A description of the expected behaviour
- *  A description of actual undesired behaviour
+ *  A description of the actual undesired behaviour
 
 Only when your bug report requires multiple source files to be reproduced should you use an archive otherwise the uploaded individual source file or diff should contain the minimal source code needed to reproduce the bug. In any case, make sure the above are included in the body of your bug report as plain text, even if needlessly duplicated as part of an archive. Please try and repeat on the current git master.
@@ -29 +29 @@
  *  E-mail messages that complement previous, incomplete bug reports. Post a new, self-contained, full bug report instead, if possible as a follow-up to the original bug report.
  *  Assembly files (*.s) produced by the compiler, or any binary files, such as object files, executables, core files, or precompiled header files.
- *  Duplicate bug reports, or reports of bugs already fixed in the development tree.
+ *  Duplicate bug reports or reports of bugs already fixed in the development tree.
  *  Bugs in the assembler, the linker or the C library. These are separate projects, with separate mailing lists and different bug reporting procedures. The RTEMS Project is happy to work with you and those projects to resolve the problem but we must work with those projects.
  *  Bugs in releases or snapshots of RTEMS not issued by the RTEMS Project. Report them to whoever provided you with the release.
  *  Questions about the correctness or the expected behaviour of programming language constructs or calls to library routines that are not part of RTEMS.
 
-Developing and debugging real-time embedded systems can be difficult. Exercise caution in reporting an error that occurs only some of the times a certain program is executed, such that retrying a sufficient number of times results in a successful compilation; this is often a symptom of a hardware problem or application issue, not of a RTEMS bug (sorry). We do recognise that sometimes a timing bug will exist in RTEMS but want you to exercise due diligence before pointing fingers.
+Developing and debugging real-time embedded systems can be difficult. Exercise caution in reporting an error that occurs only some of the times a certain program is executed, such that retrying a sufficient number of times results in a successful compilation; this is often a symptom of a hardware problem or application issue, not of a RTEMS bug (sorry). We do recognise that sometimes a timing bug will exist in RTEMS but we want you to exercise due diligence before pointing fingers.
 
 == Not RTEMS Bugs ==
@@ -55 +55 @@
   a. Add a useful single line summary.
   a. Set the `Type` field to `defect` for a bug. Note `infra` is used to report issues with the RTEMS servers at OSUOSL.
-  a. Set the `Version` field. If it is with the current git master branch use the next version
+  a. Set the `Version` field. If it is with the current git master branch use the next version.
   a. Set the `Component` field and leave as `General` if you are not sure.
   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.
@@ -94 +94 @@
 
   '''open''':: The ticket has been filed and the responsible person(s) notified.
-  '''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.
+  '''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 stating who tested the bug and when.
 
 The `resolve` action has the following: