Process for defect approval in shutdown mode
This is the documented process for defect approval in shutdown mode
as reviewed and approved during the TPTP f2f meeting, on January 2007 and
modified based on PMC meeting on April 8, 2009:
- The developer seeks for Project Lead approval by sending a request to the corresponding project mailing list. Each approval request must be accompanied by a completed stop ship request template added to the bugzilla defect, as described below. If the Project Lead approves the request, then:
- The project lead will put a "?" in the "pmc_approved" flag and put the following emails of the PMC members into the "pmc_approved" field:
- firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
This process is applied during the following points of a release:
- Last week of development in a full release iteration.
- Last iteration in a full release.
- All iterations in a maintenance release.
Stop Ship Request Template
When requesting approval to check in a fix when TPTP is in stop-ship mode, post answers to the following questions in the bugzilla defect before seeking project approval.
- Explain why you believe this is a stop-ship defect. How does the defect manifest itself, and how will users of TPTP / consuming products be affected if the defect is not fixed?
- Is there a work-around? If so, why do you believe the work-around is insufficient?
- Is this a regression or API breakage? Explain.
- Does this require new API?
- Who performed the code review?
- Is there a test case attached to the bugzilla record?
- What is the nature of the fix? What is the scope of the fix? What is the risk associated with this fix?
- Is this fix related to any standards that TPTP adheres to? If so, who has validated that the fix continues to adhere to the standard?