Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "WTP PMC Defect Review"

m (Overview of Steps Required:)
Line 36: Line 36:
 
*If approval is given, the developer may then release the code (tag with version and update map files) for a build.
 
*If approval is given, the developer may then release the code (tag with version and update map files) for a build.
  
 +
 +
== PMC Members, How to vote ==
 +
 +
*Instead of using a "+1" comment, you update the "pmc_approved" flag for your email address with a "+" for approve and a "-" for reject.  Once the developer puts a bug in "PMC", John will add you as a CC and add your bugzilla flags as a "?", which will generate you a handy email, requesting you to approve the bug.  Once the appropriate amount of approvals is garnered, John will update the status whiteboard to "PMC_approved" or if need be, to "PMC_rejected".  The PMC pages are updated to ONLY look at the flags and not text comments.
 +
 +
 +
== References ==
  
  

Revision as of 16:47, 16 May 2007

WTP PMC Defect Review

As the end of a release cycle nears, WTP needs to add some governance in order to maintain stability and quality in the face of the upcoming deadline. To this end, a PMC review process will occur.

Important Note - The PMC Review is not an in depth technical accuracy review, but a general risk management analysis of possible benefits and associated risks of including a proposed fix.


How To Prepare a PMC Defect Candidate

The answers to the following bullets must be incorporated into the bugzilla entry before a defect will be considered for PMC approval:

  • Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such.
  • Is there a work-around? If so, why do you believe the work-around is insufficient?
  • How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added?
  • Give a brief technical overview. Who has reviewed this fix?
  • What is the risk associated with this fix?

How To Get a PMC Defect Candidate Approved

Overview of Steps Required:

  • Developer obtains component lead approval, fixes defect, and attachs patch to the defect.
  • Developer also adds documentation about the fix and why it is a mustfix.
  • Developer gets component review and the component lead (or delegate) documents their review and approval, and puts "PMC" in the Status Whiteboard field.
  • Component Lead sends a note to wtp-releng@eclipse.org with a link to the defect. (You must be a member of this list to send mail to it.)
  • PMC members review and vote. A single negative vote will reject a defect and a minimum of two positive votes is required for approval. It will be incumbent on the PMC to do anything possible to perform reviews within 24 hours. If the bug is approved, the Status Whiteboard is updated to "PMC_approved" by release lead. If the bug is rejected, it will be updated to "PMC_rejected" and the code should not be released for a build.
  • If approval is given, the developer may then release the code (tag with version and update map files) for a build.


PMC Members, How to vote

  • Instead of using a "+1" comment, you update the "pmc_approved" flag for your email address with a "+" for approve and a "-" for reject. Once the developer puts a bug in "PMC", John will add you as a CC and add your bugzilla flags as a "?", which will generate you a handy email, requesting you to approve the bug. Once the appropriate amount of approvals is garnered, John will update the status whiteboard to "PMC_approved" or if need be, to "PMC_rejected". The PMC pages are updated to ONLY look at the flags and not text comments.


References

Back to WTP Build Process and Procedures
Back to Web Tools Wiki Home

Back to the top