Skip to main content
Jump to: navigation, search

Difference between revisions of "WTP PMC Defect Review"

 
(30 intermediate revisions by 10 users not shown)
Line 1: Line 1:
 
= WTP PMC Defect Review =
 
= WTP PMC Defect Review =
  
<i>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. </i>
+
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.  
  
<b><u>Important Note</u> - 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. </b>
+
Additionally, while extremely rare, there are some problems that can not be solved without a change in API behavior. Since these changes can have very large impact on adopters investments, any change in the behavior of a released API (whether in maintenance release or not) requires PMC review and approval. If a PMC Review is being requested due to an API change, the developer or Project Lead should add an explicit comment "PMC Review requested due to API change".
 +
 
 +
<b><u>Important Note</u> - 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. Unless it's a Blocker or Critical (crashes Eclipse or causes data loss), think hard about whether it needs to go into this particular release and not wait for the next quarter's.</b>
 +
 
 +
== How many votes are needed? ==
 +
 
 +
As of the switch to quarterly SimRels, due to the compressed time span, the rule is:
 +
 
 +
* RC1 (begin PMC +1 after declare)
 +
* RC2 (begin PMC +2 after declare, but by then it's Quiet Week and you'll need to make a strong case for the change)
  
  
 
== How To Prepare a PMC Defect Candidate ==
 
== 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: ====
+
==== 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.
 
*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.
Line 24: Line 33:
 
==== Overview of Steps Required: ====
 
==== Overview of Steps Required: ====
 
   
 
   
*Developer fixes defect and attaches fix patch to the defect.
+
*Developer fixes defect and attaches fix patch to the defect or a referencing Gerrit change.
  
*Developer also adds documentation about the fix and why it is a must fix.
+
*Developer also adds documentation about the fix and why it is a must fix (using the template: [http://wiki.eclipse.org/WTP_PMC_Defect_Review#How_To_Prepare_a_PMC_Defect_Candidate How To Prepare a PMC Defect Candidate]).
  
*Developer asks for component lead review and the component lead (or delegate) documents their review and approval.
+
*Developer asks for Project Lead (or delegate) review and the Project Lead (or their delegate) documents their technical review (set the '''review''' flag) and approval.
  
*Component lead then:
+
*Project Lead (or their delegate) then:
:*Puts "PMC" in the Status Whiteboard field
+
:*Puts "PMC" in the Status Whiteboard field.
:*Adds hjzhang@ca.ibm.com as a CC to the bug.
+
:*Adds the following to the '''pmc_approved''' flag with a "?". You can copy/paste the whole line in one field.
:*Adds the following to the '''pmc_approved''' flag with a "?". You can copy/paste the whole line in one field.  
+
:::david_williams@acm.org, raghunathan.srinivasan@oracle.com, naci.dai@eteration.com, neil.hauge@oracle.com, cbridgha@us.ibm.com, ccc@us.ibm.com, vrubezhny@redhat.com, eyuen@ca.ibm.com, nitind@pobox.com
:::david_williams@us.ibm.com, raghunathan.srinivasan@oracle.com, naci.dai@eteration.com, deboer@ca.ibm.com, neil.hauge@oracle.com
+
 
::This will add PMC approval flags for each PMC member and automatically send the PMC member an email.
 
::This will add PMC approval flags for each PMC member and automatically send the PMC member an email.
  
*PMC members review and vote.  A single negative vote will reject a defect and usually 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. To see if a bug is approved, the developer can watch the associated PMC approval PHP page, which will be dynamically updated.
+
*PMC members review and vote.  A single negative vote will reject a defect and usually a minimum of two positive votes is required for approval.  It is incumbent on the PMC to do anything possible to perform reviews within 24 hours.  
  
*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 commit and push the changes for a build.
  
*If the component lead does not get 24 hour turnaround on approvals, they should send 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.)
+
*If the Project Lead (or their delegate) does not get 24 hour turnaround on approvals, they should send a note to [mailto:wtp-pmc@eclipse.org wtp-pmc] with a link to the defect.
  
 
== PMC Members, How to vote ==
 
== 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 appropriate amount of approvals is garnered, Helen will update the status whiteboard to "PMC_approved" or if need be, to "PMC_rejected".  The PMC summary web pages are updated to ONLY look at the flags and not text comments.
+
*Instead of using a comment to indicate "+1", you need to update the "pmc_approved" flag for your email address with a "+" for approve and a "-" for reject.
  
 +
*Note that it is the votes (and number of votes) that determines if/when a fix is "approved". Eventually, as an administrative task, the white board status field will be changed from 'PMC' to  'PMC_approved' by a PMC member or the Releng Lead. It is important to have this field up to date only when increasing the 'number of votes required for approval', or else the summary page may start to show previously approved fixes as still needing more votes.
  
== Junit updates needed during PMC Review peroid ==
+
== Q & A ==
*Committers can release Junit changes without waiting for approval, however the bug should still be marked for PMC review as usual.  This so so everyone would be informed of the changes in case if it caused a build break or if teams are wondering why a build was kicked off when no changes were released.
+
:* Q: Do JUnit changes require PMC approval as well?
 +
:* A: Committers can release JUnit changes without waiting for approval, however the bug should still be marked for PMC review as usual.  This so so everyone would be informed of the changes in case if it caused a build break or if teams are wondering why a build was kicked off when no changes were released.
  
  
 
== References ==
 
== References ==
[http://www.eclipse.org/webtools/plans/2.0.2/pmc-bug-approval.php Current approval candidates]
+
Current:
  
;[[WTP Build Process and Procedures | Back to WTP Build Process and Procedures]]
+
[http://www.eclipse.org/webtools/plans/3.5.1/pmc-bug-approval.php 3.5.1 candidates]
;[[Web_Tools_Project | Back to Web Tools Wiki Home]]
+
  
[[Category:Eclipse Web Tools Platform Project]]
+
[[Category:WTP Build Related| ]]
 +
[[Category:Process and Policies| ]]

Latest revision as of 15:54, 30 August 2018

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.

Additionally, while extremely rare, there are some problems that can not be solved without a change in API behavior. Since these changes can have very large impact on adopters investments, any change in the behavior of a released API (whether in maintenance release or not) requires PMC review and approval. If a PMC Review is being requested due to an API change, the developer or Project Lead should add an explicit comment "PMC Review requested due to API change".

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. Unless it's a Blocker or Critical (crashes Eclipse or causes data loss), think hard about whether it needs to go into this particular release and not wait for the next quarter's.

How many votes are needed?

As of the switch to quarterly SimRels, due to the compressed time span, the rule is:

  • RC1 (begin PMC +1 after declare)
  • RC2 (begin PMC +2 after declare, but by then it's Quiet Week and you'll need to make a strong case for the change)


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 Fix Candidate Approved

Overview of Steps Required:

  • Developer fixes defect and attaches fix patch to the defect or a referencing Gerrit change.
  • Developer asks for Project Lead (or delegate) review and the Project Lead (or their delegate) documents their technical review (set the review flag) and approval.
  • Project Lead (or their delegate) then:
  • Puts "PMC" in the Status Whiteboard field.
  • Adds the following to the pmc_approved flag with a "?". You can copy/paste the whole line in one field.
david_williams@acm.org, raghunathan.srinivasan@oracle.com, naci.dai@eteration.com, neil.hauge@oracle.com, cbridgha@us.ibm.com, ccc@us.ibm.com, vrubezhny@redhat.com, eyuen@ca.ibm.com, nitind@pobox.com
This will add PMC approval flags for each PMC member and automatically send the PMC member an email.
  • PMC members review and vote. A single negative vote will reject a defect and usually a minimum of two positive votes is required for approval. It is incumbent on the PMC to do anything possible to perform reviews within 24 hours.
  • If approval is given, the developer may then commit and push the changes for a build.
  • If the Project Lead (or their delegate) does not get 24 hour turnaround on approvals, they should send a note to wtp-pmc with a link to the defect.

PMC Members, How to vote

  • Instead of using a comment to indicate "+1", you need to update the "pmc_approved" flag for your email address with a "+" for approve and a "-" for reject.
  • Note that it is the votes (and number of votes) that determines if/when a fix is "approved". Eventually, as an administrative task, the white board status field will be changed from 'PMC' to 'PMC_approved' by a PMC member or the Releng Lead. It is important to have this field up to date only when increasing the 'number of votes required for approval', or else the summary page may start to show previously approved fixes as still needing more votes.

Q & A

  • Q: Do JUnit changes require PMC approval as well?
  • A: Committers can release JUnit changes without waiting for approval, however the bug should still be marked for PMC review as usual. This so so everyone would be informed of the changes in case if it caused a build break or if teams are wondering why a build was kicked off when no changes were released.


References

Current:

3.5.1 candidates

Back to the top