Friends of Eclipse,
Eclipse is an open source community that benefits millions of developers around the world each and every day! During the month of September, we are asking you to give back to our wonderful open source community. All donations will be used to improve Eclipse technology. Your contribution counts!
We thank you for this gesture, and for giving back to our community.
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 ... ...
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.
Back to meeting list.
Please send any additions or corrections to David Williams.
Back to the top