Skip to main content
Jump to: navigation, search

WTP 2010-02-11

WTP Development Status Meeting


Project Leads

Note: feel free to correct any errors/omissions in above attendance record.

Remember, any committer can add an agenda item. Typically, short announcements or news items go in the "Announcements" section at the beginning. Longer items or issues requiring discussion should go in the "Other business" section at end.

Announcements And Special Reports

  • New Common Project Lead

WTP Calendar

(Weekly Google Calendar updated through June, 2010)

For Galileo and Helios overall dates, see a Simultaneous Release Calendar

Quality Focus Items (Neil)

  • Focus Item:
  • Mark invalid patches as obsolete
  • Target bugs to a release or "future" if not a current release

WTP 3.1.x


See also the Galileo ramp down dates

WTP 3.1.2 - Galileo SR2

02/05 M Build for SR2 RC3 Can this be our final build? (PMC +2 after this build declared)
02/12 R Build Final Build (PMC +3 after this build -- typically only "damaging" bugs approved).
(02/26 Galileo SR2) (WTP 3.1.2) (fourth Friday of February)
The time between 2/12 and 2/26 is meant for final adopter testing, web pages, update testing, etc.


Major bugs targeted and unresolved for 3.1.2 or 2.2.2
P1 bugs targeted and unresolved for 3.1.2 or 2.2.2
All targeted and unresolved for 3.1.2 or 2.2.2
resolved for 3.1.2 or 2.2.2

Required PMC Review remains in effect.

Galileo Maintenance Plan

See WTP_3.1.x_Maintenance for documentation of scope of maintenance and approvals required.

WTP 3.2

  • Bugs
Blocker and Critical
P1s that need attention
bugs targeted to 3.2


M6 03/12 - API, UI Freeze. Accessibility Reports.
M7 04/30
RC1 05/14 (followed by weekly RCs, if needed)
Final WTP 3.2 build 06/10
(06/23 Helios Release)

Note: these (and our plan dates) are on 'Friday' of the week. But, we produce and test the build on Thursday of the week, and ideally declare on Thursday. The dates in the Google Web Tools group calendar are for 'Thursdays' since that's a calendar for committers. We give ourselves the buffer to Friday, as our "public" date, that others can pick up our build, just in case a regression is found on Thursday and we have to respin and retest. [Technically, some might say, we still have till the following Tuesday or Wednesday for "Simultaneous Release" due date ... but it's hard to do much in that window, without disrupting everyone ... so we'd not use that buffer, except for the worst emergencies.]

Other business

Each project is still responsible for their own ... but we'll report a "rolled up" version for release.
  • we require some quick changes for JUnit V4
  • Accessibility checklist required by end of M6 (at latest)

The Simultaneous Release Requirements have an Accessibility Requirement to report Accessibility Compliance by using "... a publically available checklist ...". While for the overall Helios Release documentation, we will provide one, "rolled up" checklist for all of WTP, the PMC would like to ask each sub-project to do their own evaluations and tests and provide their own checklist report, specific to their sub-project. For consistency, we recommend the sub-projects use these publically available lists (they were chosen because they have a good orientation to "developers" with useful reference links to examples, etc.):

Additionally, where tools are used to test compliance, we recommend JAWS be used. (This is not free, open source software, so we can not require it, but we know a number of committers do in fact have versions or licenses to use it, so, when possible, for consistency, would be good to use it.) There are other tools available, as mentioned in The Simultaneous Release Requirements. Also, be sure to read the updated Eclipse Corner Article, Designing Accessible Plug-ins in Eclipse for how to program in Eclipse for accessibility.

Note: This Simultaneous Release Requirement is to document our accessibility compliance, or lack of it. The requirement is not that there be no accessibility bugs. Those should be open, when found, but then prioritized along with all other bugs as to severity, importance, etc.

TODO: create a wiki "form" representing the above lists, for sub-projects to fill in.


WTP 3.1 Post Mortem

ramp down plan and policies

See also the WTP Meeting Archive-Reference Page.

Back to the top