Skip to main content

WTP PMC Agenda/Minutes for December 07, 2010 Conference Call

WTP PMC Agenda/Minutes for December 07, 2010 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: R
  • Kaloyan Raev: Y

Announcements and General Business

  • JPA Diagram Editor
    Discuss issue where Graphiti is still incubating for Indigo?

    We discussed and decided the following points:

    • As a matter of policy, WTP released projects can depend on other incubating projects, but we agree it is an exception, and requires PMC review and approval. The PMC will assess cost/benifits/risks etc., and depends on if the incubating project is released, it relatively mature, impact to adopters, etc. (and, we approve it for the JPA Diagram Editor, depending on Graphiti).
    • We do believe it is fine for JPA Diagram Editor to "graduate" (if it were a true project), as graduation is more a matter of "project state" ... does is operate well, follow "the Eclipse Way" with community and adopters, etc., not so much the maturity of its API ... noting that API stability is always a matter of "API Policy" of a project and can vary from project to project.
    • We would not put JPA Diagram Editor (or any incubation feature, or feature that depends on incubating feature) directly in the JEE Package. This is because if we did, we'd need to include a note similar to "this package includes incubating features" and we fear that would make it seem "less ready" for use, less mature.
    • The JPA Diagram Editor, and Graphiti, would still be in the common repository, /releases/helios, and relatively easy for users to install. Presumably, at some point in that installation (such as list of feature/bundles) to be installed, the incubating components would be identified as incubating.
    • Still ok for JPA Diagram Editor to release with Indigo at "1.0" level, especially since it doesn't any APIs to speak of.
    • "project vs. sub-project" decision should be based on goverance concerns and desire to release independently, not architecture or packaging. JPA Diagram editor won't want to release independently in future (the one time was only to have a Helios version released.) And everyone felt social conventions in Dali would suffice for governance. Hence one project (Dali) suffices and we'll do move review, instead of creation review.
    • From EMO's point of view, it is strictly a move review, but convention, when WTP Incubator components "graduate" (move) we still expect the component team to provide documentation similar to that which would be found in a project graduation review.
    • For features, builds, map files, etc., will keep things as seperate as possible. Will have one new 'component' in Dali's bugzilla.
    • Kaloyan will start move review docuware. He will provide "committer info" for two committers for JPA Diagram editor, but Neil will "nominate" them for vote of other Dali committters (as is required for move). We (they) still need to check EDP and check on details of "move review" to decide if vote must be done on mailing list, as part of move review, or if they can use portal and say "contingient on successful move review".
  • Anything else?

    Kolyan gave update on Trademark issue: it has been established no one can use "OSGi <anything>". They are now looking at something like "Enterprise Tools for OSGi Platform". Note the project's "short name" will be "Libra" and package namespace will be "org.eclipse.libra".

    Neil gave "heads up" that they want to "include" (or depend on) some Eclipselink bunles that do JPQL parsing in Dali features (for validation, and code completion). The PMC did want to make sure we are sensitive to adopters and not give any appearance to an end-user of "depending on EclipseLink runtime" but Neil said no, just a few bundles that would not surface in any end-user UI ... they would not see "eclipselink runtime" installed, or anything similar. We'll work out how to "reship" those bundles similar to how we would Orbit bundles, so we don't have to instruct users to "go and install the EclipseLink runtime". If those bundles are not singletons, would be especially easy. If they are singletons, will need to use extra care to make sure same version is used by WTP and EclipseLink.

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?

References

Back to meeting list.

Please send any additions or corrections to David Williams.

Back to the top