NOTE: This is work in progress

OpenSAF Defect Handling Checklist

OpenSAF Project

• OpenSAF support two last functional releases plus ongoing development release
• Question: What is done when closing an maintenance release with all open Defects mapped to that release.
  • Alternative A: All tickets are closed (Won’t fix)
  • Alternative B: TLC goes through the tickets and selects which once are mapped to subsequent maintenance release
  • Alternative C: Critical & major are mapped to Last supported maintenance release.

Use Cases:

1. Reporting Defect
2. Solving Defect

UC-1: Reporting Defect

Actors: OpenSAF User

1. OpenSAF User checks if the problem is already reported or solved in later version of the system by querying OpenSAF Ticket system and mail backlogs.
2. If this is a new problem OpenSAF User reports problem by creating OpenSAF Defect Ticket and following guidelines displayed in ticket creation form

UC-2: Solving defect

Actors: OpenSAF Developer, OpenSAF Maintainer

1. Developer indicates that it plans to provide a fix for specific ticket by accepting the ticket
2. Developer creates patch that follows OpenSAF Coding Guidelines described here (TODO add link)
3. Developer MUST test patch on the version reported in the ticket
4. Developer sends patch on the developer mailing list following THIS (add link) process
5. Developer must address ALL the comments received
6. If comments required change to the patch process starts again from step 2.
7. If ACK is received from maintainer and all comments are incorporated in latest distributed path then such patch is FINAL patch

Maintainer

1. Maintainer receives patch review request; and comments on the patch within 3 working days
   1. Note that other Developers can send comments to the patch; but only maintainers can ACK the patch
2. Maintainer commits FINAL patch to the staging repository of Version referred in ticket
3. Maintainer transplants patch to all supported and relevant versions according top process described here (TODO add link)