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.