Mik: Help > Report this bug ... button in every distro that includes Mylyn been doing more harm than good so far

Kevin McGuire wanted to get bug auto-reported against Distro rather than component?

Boris: Platform UI tries to redirect bugs properly, not too big an issue for them

Martin: Windows 7 "Report a enhancement request with THIS component"

... they set the expecatation like "We won't respond but your comment is valuable"

Mik: new "report bug" wizard allows to select any feature that has UI

Boris: "report bug" wizard could show a webpage with (paid) ads of companies for commercial support... commercial products could replace that by their commercial support page

Mik: Mylyn has an extension point for registering commercial support

AI Mik to propose a date for demoing the feature at EclipseCon

Doug Gaff (added after the meeting): I just want to summarize this by reminding folks that the EMO committed to 1) indicating that EPP packages are community support only and 2) providing links to Vendors that offer supported, commercial distros. Beyond this, it's in the community's hands.

Platform clients have problems updating to newer Eclipse versions, in spite of remaining binary API compatible. Do others see this too?

How can inevitable migration effort (e.g. due to fixing semantic errors in API) be eased?

Tagging change / tools to detect change

How can we help clients become API-clean, and how can we help protect investment where API cleanliness is impossible?

Tools to report usage of non-API even in closed source

Allow clients to contribute unittests for code where they (have to) leverage internal non-API, in order to detect breakage early

How can we help clients detect usage of obsoleted features, and migrate to the new replacement feature more easily?

API Deprecation Policy / Soft deprecation tag

Is it reasonable to expect API-clean clients?

Dave Williams: Semantic differences are hard; in WTP, there are tools for scanning code and reporting back; would like to see PDE API Tools move into usage scanning as well

McQ: Want scanners on beyond-bundle-granularity to report usage. Should we do that between projects? Setup a database for the information?

Jeff: Low-fidelity / high-fidelity analyzers of usage

Martin: are we softening the "You must be API clean" story?

McQ: we should still be talking about "you must be API clean", but how can we live with reality? API does change. Take the low-level SWT event mechanism for instance. Can we tag non-API as "you're OK to use it"?

DaveW: at this point, we should be collecting information and then decide on what to do with the information.

Dave Carver: often, there is no way doing something without going "internal". How many people have actually requested something become API?

Report will also be good to find out what non-API should be made API

McQ: Formal deprecation policy?

Jeff: Setup another call for the deprecation thing? Start up simple and start a scanner for all of Eclipse.org

Darin: API Tooling currently working on scanners to discover references between plugins, generating report or dumping into a DB