Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

DTP Retrospective, January 2007

Revision as of 17:49, 19 January 2007 by Unnamed Poltroon (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Back to DTP Main Page

Introduction

This page contains retrospective input collected during early January 2007 regarding the DTP 0.7, 0.9 and 1.0 releases. The data is presented in no particular order, and is meant to spur discussion.

Retrospective Input

  • Define a set of prioritized project level goals for DTP. Specific goals should be defined and prioritized for each of the subprojects. Ideally, these should relate to top level DTP goals. Some suggestions:
    • Elevate provisional API to platform status
    • Improve unit test coverage
    • Improve documentation
    • Ensure all API are documented
    • Add general documentation (e.g. best practices, examples, etc.)
    • "fix" any API that are found to be awkward or inadequate
    • Improve "generic" feature set
    • Expand generic DDL generation support to include SPs, UDFs, etc.
    • Visual SQL editor
    • Improve build system
  • Document contributor process
    • Define best practices for defect logging
    • Define defect prioritization
    • Defects with patches attached
    • Defects related to release goals
    • Other defects as time allows
  • For 2.0, we might have the following:
    • Improve overall usability
    • Clean up DB profile-driver definition usage model (e.g. reduce the number of driver definitions)
    • Improve SQL editor profile selection dialog (e.g. simply present a list of profiles) etc...
    • Increase number of specialized implementations (i.e. focus on enablement)
    • Increase adopter base
    • Focus on extension providers
    • Focus on integrators (this may be part of 1.5, e.g.: WTP, Dali)
  • I think it would help to have the currently documented project plans go beyond the next big (major/minor) release.
  • As for patch releases, I think these should occur as required. That said, I think we should define place holder releases to give external entities the ability to plan for them. For example, hypothetically, we could specific a date for a 0.9.2 release, but the release would only occur if there were a demand for it (e.g. somebody came and said I really need this defect fixed in the 0.9 release). Any which way, this should be documented so the community knows what to expect (and how to go about getting what they want).

Back to the top