Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
WTP 2010-02-11
Contents
WTP Development Status Meeting
Attendees
|
|
|
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:
- Untargeted bugs with patches attached opened before Jan 1st, 2010 (Current: 15, Last week: 16)
- Options:
- Mark invalid patches as obsolete
- Target bugs to a release or "future" if not a current release
WTP 3.1.x
- Ready to declare latest build?
Schedule
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.
Bugs
- 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
- Ready to declare latest build?
- Bugs
Schedule
- 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
- knew you could combine IP Logs?
- Each project is still responsible for their own ... but we'll report a "rolled up" version for release.
- We need to improve website and logo? See bug bug 301940 and bug bug 300475.
- we require some
quickchanges 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.
References
See also the WTP Meeting Archive-Reference Page.