Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
DTP PMC Meeting, January 6, 2009
Revision as of 15:26, 6 January 2009 by Brianf.sybase.com (Talk | contribs)
← Back to DTP PMC Meeting Page
Attendees
- Brian Fitzpatrick
- Linda Chan
- John Graham
- Brian Payton
Regrets
Agenda
- Discussion of features question (Currently all top-level features and sub-features(totally 30) are listed in Galileo site as top-level. Can we reduce the feature number?)
- Discussion of min/max versions for Galileo (started in BZ 201125 https://bugs.eclipse.org/bugs/show_bug.cgi?id=201125 )
- Further discussion of March Webinar
- Discussed possibly doing the Webinar on the SQL Query Builder and having Duncan lead it, with some help from Linda. Showing SQB functionality and how it integrates with BIRT.
- Original Item: Webinar in March 2009? 40-45 minute technical presentation and demo, 15 minutes of questions at the end. Lynn was shooting for March 5 at 12:00 pm EST as a starting point. She's looking for one person to present, and another to type up responses to questions as they come up during the presentation.
- Open discussion
Minutes
- Discussed Delta Pack as a possible solution to the features question as an easier way to handle it. We're not sure it applies. One option is to just include the Derby/Generic JDBC case in Galileo and then add the others via the update site. Another option is to expose an aggregate set of features, but still have the granular features available as separate features on the update site. (Duplication might be confusing if we went this way.)
But it boils down to the fact that P2 may not actually scale well. Tough to go back to the days of minimal features for those folks depending on them. Possibly bring this up at the Planning Council. Reducing DTP features won't solve the long term problem. An All in One is going to be untenable with more and more features added over time also.
- For minimum version, possibly have each plug-in developer update the minimum version as required (like for the access warnings issue noted in Connectivity, those now would require 3.4). But be sure to list in the statement of supported platforms that we strictly support 3.4 as a minimum, but do this on a plug-in by plug-in basis by developers. Unless there's a reason to update the minimum version (i.e. something's broken), then we won't update it.