Skip to main content
Jump to: navigation, search

WTP 2011-10-20

WTP Development Status Meeting

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 and Noteworthy for M3?
  • 10th Anniversary Democamps, anyone available to showcase WTP?

WTP Calendar

(Weekly Google Calendar updated through December, 2011)

For Juno/Indigo overall dates, see the Simultaneous Release Calendar

Focus on Quality (Neil)

  • Improve:
  • Triage:
  • Target to a specific release or "future" if planning to fix but not in the next release
  • Adjust severity as appropriate

WTP 3.2.5

  • Delayed smoketest - no builds until this morning due to recent PMC reviewed defects
  • All sub projects required to smoke test this week until end of release

3.2.5 Schedule

10/21 M build (after this build, begin +3)
10/28 M build final build (with one week of buffer following this week, quiet week, until 11/4 (re-spin would require +3))
11/4 WTP 3.2.5 GA

See "references" [1] for detailed explanation of what these dates mean.

3.2.5 Bug Review

wtp 3.2.5 pmc review bug list
Bugs targeted to 3.2.5

WTP 3.3.2

3.3.2 Schedule

10/20 M Build


1/26 M build (after this build, begin PMC-review ramp-down (+1 begins))
2/2 M build (after this build, begin +2)
2/9 M build (after this build, begin +3)
2/16 final M build (with one week of buffer following this week, quiet week, until 9/23 (re-spin would require +3))
2/24 SR2 GA

Bug Review

Bugs targeted to 3.3.2
Hotbugs [2]
Blocker and Critical

WTP 3.4.0

  • Found problems with 4.x based builds? We wish to start tracking these issues, and will publish query.
  • Juno Project planning

3.4.0 Schedule

10/20 I-build declare
10/27 I-build declare
11/4 M3 declare

Bug Review

Bugs targeted to 3.4.0
Blocker and Critical

Other business

  • Smoketest discussion
    • We had a discussion several weeks ago regarding expectations for projects smoke testing each weekly declared build, and in the case of WTP 3.2.5 allowed teams to skip if they didn't contribute to the release. We understand the heavy workloads of many teams, and want to be flexible, while maintaining stability and limiting risk for adoption on our declared drivers.
    • We (PMC) are proposing that the 3.3.2 maintenance builds will only require smoke tests if teams have contributed that week, or dependencies have changed. If not, project leads have the discretion to skip. We will have this policy until around mid December, when we will start mandatory smoke testing this release. This should give some flexibility to the project leads. The 3.4 release will remain mandatory every week.
  • Review additional API "Guidelines"
    • Thinking of making a change that effects a public or private api? Our goal is to maintain a stable, low risk, and safe environment for maintenance releases, while also allowing a flexible but well documented policy for API change in any current development release. These guidelines should help determine the best course of change to a component.
    • Maintenance release:
      • Breaking changes to public API is never allowed. Non-breaking changes to public API is discouraged but exceptions must be reviewed by the PMC. Changes to existing internal api is discouraged, and an new alternate api is always preferred. If making a change to an existing Interface class, always consider adding an extension interface to prevent breaking adopter implementers. API also includes extensions point declarations and implementations if backing api classes (Example: Facet/Runtime extensions and classes). Adding features in a maintenance release is discouraged, exceptions should be brought to PMC, and a separate feature release should be considered to minimize adopter risk.
    • Current or Maintenance release:
      • In any release (maintenance or current) any api change that causes backward compatibility breakage must be reviewed by the PMC. Any non-breaking change to an existing api in a current release is allowed but should be well documented, and shared with the community.
  • Anything else?

Indigo release retrospective


  1. 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 some "Simultaneous Release" due dates ... but it's hard to do much in that window, without disrupting everyone ... so we'll not use that buffer, except for the worst emergencies.]
  2. Hotbug Policy

Also, see

Indigo SR2 Simultaneous Release Schedule
Standard Format Plans
WTP 3.2.x maintenance release plan
how/when to branch code?
IP Logs selector
WTP Helios retrospective.
See also the WTP Meeting Archive-Reference Page.

Back to the top