This will only affect PMC members, who will instead of voting with text of "+1" in a comment, will use the "PMC_approved" flag with a value of "+" or "-". Business as usual for committers who will still put the "PMC" into the whiteboard which will be updated to PMC_approved as appropriate. Please remember to add jlanuti@us.ibm as CC for all PMC bugs.

April 6th - May 18th, WTP RC0

April 2007 - May 2007

Monday

Tuesday

Wednesday

Thursday

Friday

07 Bug Fixing Start component lead change approval

08 Bug Fixing

09 Bug Fixing

10 Status Call Smoke Test

11 Declare I Build EMF M7 produce test candidate

14 Function and Compatibility Tests

15 Defect Verifications Mustfix defects

16 Defect Verifications Mustfix defects

17 Defect Verifications Status Call Thumbs Up Test

18 Declare WTP 2.0 RC0

Build Status

Platform M7 declared this week. EMF and GEF M7 next week.

Please smoke test and update wiki to declare RCO I Build.

JUnits all passing.

RC0 New and Noteworthy - Nitin to start the new and noteworthy process for RC0 for those components who added new function.

API Violations Review - Cannot underestimate the importance of this in the stability and quality of WTP as a platform. These numbers are embarrassingly high. Each component needs to really get someone focused each week on improving these numbers and opening API requests.

Action 1 = For any violation, open a bug to request API or fix code to not use internal discouraged access. An example is using images or labels from other plugins, these should be copied into your plugin. Also, using internal classes instead of the API interfaces.

Action 2 = If you do have a clean plugin of API violations/discourage access, switch prereq ranges wide so you can react to small version number changes without issue.

Action 3 = To be able to develop with discouraged access enabled, we need to update plugin's .classpath rules. Should we turn off defaults to expose all warnings to get a quicker resolution?