Enhance user tools to make DTP a compelling choice for developing data centric applications in Eclipse by providing additional exemplary tools in a variety of areas, including creation of database objects such as catalogs, schemas, tables, columns, constraints, and so on.

Enhance DTP to work better in headless and RCP applications.

Accurately prioritize and address bugs, especially those having a severity of major or higher.

Grow the DTP community through direct contributions and external projects using DTP components.

Make DTP easier to understand and leverage, from both the extender and user perspectives.

Meet milestone dates in tight synchronization with Galileo plans.

ODA-related

Define filtering spec for support by any ODA data source queries

Support for Multi-dimensional Result Sets

Enhance ODA Framework and API to support advanced features requested by the community. For example, dynamic creation of connection profile instance, support ODA data source-defined object type.

IBM's Goals for DTP Galileo

Additional SQL syntax coverage in the SQL Parser/Model

Enhancements and bug fixes in the SQL Query Builder

Enhancements for Model base

And an overall theme of quality, usability, and reducing inhibitors to adoption

Need Community Feedback

DTP is wondering about JDK support. Some Eclipse projects have moved to using JDK 1.5 as their base level of JDK support. DTP has been supporting JDK 1.4 and up. Are there compelling reasons to move to JDK 1.5 as the Java level we use during builds?

What other issues exist preventing your adoption of DTP? Are there any key issues we need to address to help new and existing adopters get more out of what's available in DTP?

Galileo, like Ganymede, is designed to shrink the lag time between platform milestones and downstream projects as the release approaches. Thus, while DTP is a "+1" dependency at the current time, DTP builds for later platform releases (typically in the release candidate periods) will appear in less than one week from the platform milestone. The DTP PMC interprets the downstream lag as an idealized upper limit, and will seek to make matching DTP builds available as soon as possible after platform milestones, typically with a 24 hour (business day) delay for testing. Hence, if a platform milestone appears on a Friday, DTP will seek to have its corresponding build by the end of the following Monday. Such builds will be designated as Integration builds and subject to further testing past that date. The general disclaimer is that DTP can not guarantee hitting these dates due to bugs that might appear in integration tests and availability of additional dependencies other than the platform (for example, EMF and GEF). Timing of DTP integration and milestones builds are detailed [| here].

Summary Timeline

Target Operating Environments

The build, test, and deployment environments for DTP Ganymede are described here.

Rampdown Policy

To avoid last-minute regressions as we saw at the end of the Ganymede M6 milestone, the PMC has decided to implement a new test period before declaring milestones. Since release candidates are subject to the Rampdown Policy, we're only concerned about later DTP milestones here (M5/M6/M7).

The new policy is: (Update dates)

Commits for M5/M6/M7 will be allowed through the build start time on (date) by 1:30pm PST

The testing period will start on (Date) and last through (Date) to be ready to push up to the site on (Date).

Committers wishing to include additional bug fixes in M7 between (Dates) must provide the following in an associated Bugzilla entry:

Document the severity and impact of the bug: why should this be included in the milestone at such a late date?

Document the proposed resolution, risk, and validation testing that will occur

Petition the DTP PMC for permission to deliver the change to the build. At least two (2) of the four (4) PMC members must approve, with no PMC member objecting, for the bug to be authorized for the M7 build.