DTP Retrospective, January 2007
Revision as of 10:49, 17 June 2007 by Remy.suen.gmail.com
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.
- 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
- Document how to join DTP
- How do you become a committer?
- How can you offer code for a new component?
- How can you propose a new subproject?
- 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).
- Use the project mailing lists more effectively:
- dtp-dev for general questions, discussions, and announcements about developing with DTP
- project lists: for detailed planning, design, and implementation discussions. Currently there seems to be a gap: the requirements are mostly captured in Bugzilla, and then code is delivered to CVS some time later. Would like to see discussion about the design and implementation on the project mailing lists, so the community can monitor and offer suggestions.
- PMC should provide an accurate committer list
- Create a committer page (like WTP) with at least the names of the committers
- Encourage committers to add information to committer page, so they are more visible to the community
- Only those members actively contributing to DTP should be committers: prune ranks of inactive committers
- DTP should get some articles on the Eclipse Corner
- PMC should work with committers to increase number of committer articles, presentations, and so on.