Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dtp-connect-dev] DTP 1.0 Readiness...

Hey all,

If you're not already aware of all the things we need to do to achieve 1.0
status, please read John's list on the DTP wiki site.
http://wiki.eclipse.org/index.php/DTP_1.0_To_Do_List

The following comments relate each section in the wiki to the connectivity
project.


Open, transparent, permeable:
All design and feature based discussions should occur on the dev mailing
list.
I will start publishing meeting minutes again, even if there was no meeting
or nothing of relevance was discussed.

Milestone work items:
All defects planned for release should have a milestone associated with
them.  When milestones are missed, the BZ entry should be updated with an
explanation.  Also, when deferring an entry to a future milestone or
release, please add something like the following to the entry:

Deferring to XXX.  <explanation>.  Please comment if this deferment impacts
your usage or adoption of DTP.

The purpose is to invite any consumers (adopters or extenders) of DTP to
raise concerns when bugs/features are deferred.

Plug-in version updates:
We need to make sure we update the build number whenever we modify the
contents of a project.  (I've been lax in this myself.)

Version tolerance specifications:
All plugins must have a version tolerance specified.

Build dependencies:
John should be notified of any changes to build dependencies (i.e. changes
to required plugins).

Work item dependencies:
Any dependencies between work items should be specified in their BZ
settings (e.g. blocking on/blocks).

Manifest files:
All plugins must use a manifest.mf descriptor (i.e. must be a 3.0 style
plugin).

About file inclusion:
All plugins must include an approved about.html file.

Plugin vendor names:
All plugins must use Eclipse.org as the vendor name.

API documentation:
Java and schema doc must be generated and kept up to date for all public
APIs.

Unit tests:
A unit test should be created for all defects that are fixed.  Unit tests
must exist for all platform APIs.

Incoming bugs:
All bugs should be dispositioned in a timely manner.  Bugs not targeted for
a release should be dispositioned to "later."

Newsgroups and mailing lists:
Please try to read/respond to newsgroup items at least once a week,
preferably once a day.

Supporting documentation:
We need to add content to the connectivity wiki site with examples of API
usage, best practices, common pitfalls, and any other cool things you might
think of.

IP issues:
If you have any questions about the IP status of a contribution or new
dependency, please raise the issue with the PMC for resolution.

Review API status:
I'd like to have each committer identify which APIs should be made public
and the level at which they should be defined.  For example, I think the
new generic JDBC catalog loader classes should be made public at a
provisional or experimental level.  I would like if each committer could
provide me with a list of packages by Oct. 30.

I will be creating BZ entries for the following items: (for tracking
purposes)
API specifications
API documentation
Basic documentation for extenders (quick start guides, reference articles,
wiki entries, etc.).
Unit tests

Please let me know if you have any questions, comments, concerns.... or if
you have your own take on things.

Thanks,
Rob Cernich

DTP Connectivity Project Lead



Back to the top