- David Williams: Y
- Naci Dai: N
- Raghunathan Srinivasan: Y
- Neil Hauge: Y
- Tim deBoer: R
- Kaloyan Raev: Y
- Chuck Bridgham: Y
Announcements and General Business
Welcome Chuck ...
Chuck to run Thursday status meetings
Time to revamp "quality focus" (make sure patches addressed quickly, etc.)?
Neil agreed we could use some focus on triaging bugs/patches. He'll look into php queries.
How are WTP Project work/roles distributed, especially releng? Equitable? Diverse?
Models of sharing releng work:
- Horizontal: Each project on their own.
- Veritacal: One reponsible for builds. One responsible for unit tests. One responsible for EPP Packages.
Unexpectedly lively discussion. Some unordered points:
- General feeling that we'd have to move to tycho/maven to be easy enough for anyone to do. (Common misconception: they all have PDE build, at their core, right? Primarily differs on how pre-reqs are specified and obtained.)
- Some concern that tycho/maven is easy to get started with, but maybe hard to change, or adopt for production, if needed. (i.e. like much software, if easy to use, hard to deviate, sort of have to take it as is. Possibly.)
- We should list requirements, so we know concretely what is needed; such as "signed", qualifiers change only if and only if code (content) changes.
- Kaloyan will "educate" us based on his experiences with Libra, via blog posts, eventually meeting with committers.
- Some interest in moving to GIT ... some not :) ... good point was it might help to "have a plan". With dates. acceptance criteria, etc.
- Only concrete advantage (to us) to move to GIT named was that it allows use of Gerrit.
- Point made that others can move (drive) to a hudson/tycho/maven build, and once ready, simply stop the CC based builds. This has advantage of getting others involved in responsible roles; not having current releng be the bottleneck.
- Overall, seemed to be the opinon to have project-based responsibility. Though is was mentioned there are advantage to have a unified build/release ... not sure how to do both. That is, while technically is it possible, but unsure what unanticipated problems would creep in.
- While not discussed during meeting (I thought of after meeting) the project based responsibility is not currently working ... no one pays attention to versioning errors, for example, until reminded ... so how can we incrementally move to project based responsibility?
- Could/should currently divide builds and tests. Maybe go further and have seperate page for each project/feature. Maybe that'd help encourage project level reponsibility?
Request for late addition of Libra to Indigo
Approved. Kaloyan to send note to PC list
Here's the proposed request to present to Planning Council:
The Libra project would like to join the Indigo Simultaneous Release. Libra will deliver two features for Indigo: WAR Products and OSGi Bundle Facet. The IP process for both of them is completed: CQ 4837  and CQ 4844 .
The WAR Products tooling has been originally developed to make the deployment of RAP applications easier. However, the tooling itself is not RAP specific and can be used for deploying any Server-Side Equinox applications. Since the RAP project is part of the Indigo Release, it really makes sense to have the WAR Products tooling in Indigo too. It will also benefit all developers of Server-Side Equinox applications. More details about WAR Products are available on the latest blog of Holger Staudacher . Installation and usage instructions are available on the wiki page .
The OSGi Bundle Facet feature links together the PDE and WTP tooling. It enable the WTP project wizards to create OSGi bundles projects, like Web Application Bundles and Persistence Bundles. It's the very first step towards providing OSGi tooling for enterprise applications. This feature will be a great complement to the PDE and WTP project that are in the Simultaneous Release since the very beginning. This feature is very well demonstrated in a short screencast . We are also in the process of writing a Getting Started guide .
Libra is still an incubating project. We think that including it in the Indigo Release will keep up the momentum and participation in the project to have this concrete goal to aim for. It will also increase community awareness and participation, if it can be in the common Indigo repository. We are confident that we can fulfill the requirements for the Simultaneous Release train. The limited scope of the first release (the above two features) enable us to quickly do all required changes. Our efforts are tracked in bug 338060 .
This request has been reviewed and approved by the WTP PMC at the 3/1 meeting.
 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4837  https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4844  http://eclipsesource.com/blogs/2011/02/02/equinoxrap-war-products-has-moved-hello-eclipse-libra/  http://wiki.eclipse.org/RAP/Equinox_WAR_products  http://www.youtube.com/watch?v=r09q9a4Qaas  https://bugs.eclipse.org/338060  http://wiki.eclipse.org/Libra/Getting_Started
CQ 4830 EJB Timer Waiting for Kaloyan.
Kaloyan will attend to this week.
JPA Diagram Editor
Do we have agreement (or a plan?) on what to do with Graphiti? 'include' or 'require'?
Should be "requires" unless reason not to. Neil will discuss with Tran to a) see if reasons b) see if work is feasible for M6.
Be sure newly renamed JPT feature chagnes are incorporated into Java EE IDE package feature, if needed
Neil will discuss with Tran to see what needs to be changed, if anything
Who, when, how much?
Chuck will initiate phone calls/discussions. Seemed to be desire (and people) to contribute ... but post Indigo
Future Agenda items
- Retrospect Helios quick maintenance release. Does it mean we weren't ready to release? Any way to improve timing in future?
- Disuss our model and assignments of "PMC Roles". Do they still make sense?
Back to meeting list.
Please send any additions or corrections to David Williams.