WTP PMC Agenda/Minutes for May 10, 2011 Conference Call

WTP PMC Agenda/Minutes for May 10, 2011 Conference Call
Back

Call Info

Toll free (in US and Canada): 888-426-6840
Access code: 6460142#
Caller pay alternative number: 215-861-6239
Full list of global access numbers

Call Time: 11:00 AM Eastern

Attendees

PMC Members

  • David Williams: Y
  • Naci Dai: N
  • Raghunathan Srinivasan: Y
  • Neil Hauge: Y
  • Tim deBoer: N
  • Kaloyan Raev: Y
  • Chuck Bridgham: Y

Announcements and General Business

Remember to monitor PMC review list for 3.3.0 end game..

Remember to monitor PMC review list for 3.2.4 end game.

Discuss validation bug.

We decided to treat as "hotbug", to review during status meetings. I also updated "hot bug description"" to make clearer that other Eclipse/WTP projects can, just for extra review.

Are we ready to release 3.2.4 on Friday? Need respin? Delay? Not ready to propose or conclude anything ... . but, as a heads-up ... ...

  • Regression related to EJBs (see bug 345006).
  • Another bug is being investigated (no bug number yet) where an OOME easily occurs with large JavaScript libraries. Not a regression, exactly, but is a scalability issue that shows up in enterprise contexts. Sill being investigated ... this is just an early heads up.

We will respin for bug 345006. Since this isn't a "simultaneious release", we will reset the "quiet week" and not officially release until 5/20, just to give a chance to confirm the rebuild went ok ... not to fix more bugs. Note: latest info is that JSDT memory issue is not suitable for "quick fix", and not that obvious in "plain" WTP so JSDT team will look at other alternatives, and (probably) fix in the next maintenance release. dw to send note to wtp-dev on Wednesday with (proposed) change to exact maintenance release date and begin formal sign-off.

Can we accommodate a 3.2.5 proposed release? First of September? Maybe November? Not ready for concrete proposal ... but should have high level discussion. Can we handle three streams at once? Can we "lighten" weekly testing load, somehow?

There were no objections, and general agreement it is better, in the sense of being more open (more transparent) to fix things in a mini-release, rather than in a lot of patch builds. Of course there is the concern about having "3 streams at once" -- we could not do three smoke tests every week, for example. Two alternatives were suggested: a) alternate maintenance testing ... Helios every other week, Indigo maintenance every other week, Juno every week, or b) perhaps agree to a policy that "any team that contributes to a build should smoke test it", still have three "declares" every week (as long as any contributions, any amount of testing) and then have one focused testing period near "ramp down" of any stream or milestone, where everyone tests, just to make sure no inadvertent side effects (such as, just as an example, where a change in XML DOM might effect JPA function). We'd also need to make clear, and agree to policy, that the 3 streams are "cumlative" ... that is, fixes in Helios also need to go in Indigo stream, and also need to go in Juno stream, to maintain parity between streams. It was also mentioned we'd need to be clear on the "message" we send ... that the extra maintenance releases were simply to provide really good quality, on a long term basis to users and adopters that need it, rather then simply expecting all adopters to move up to new release every year. That is, we are not doing it because a stream has bad quality, or anything.

Other Business ... ?

Future Agenda items

  • Discuss our model and assignments of "PMC Roles". Do they still make sense?

References


Back to meeting list.

Please send any additions or corrections to David Williams.