* [[Image:Ok_green.gif]] '''Martin''' Ask PC to think about an "e4 ready" requirement for next year's train

* [[Image:Ok_green.gif]] '''Martin''' Ask PC to think about an "e4 ready" requirement for next year's train

* [[Image:Ok_green.gif]] '''Martin''' Ask e4 team to pitch a migration talk at EclipseCon.

* [[Image:Ok_green.gif]] '''Martin''' Ask e4 team to pitch a migration talk at EclipseCon.

Line 84:

Line 76:

==== e4 - current state of affairs ====

==== e4 - current state of affairs ====

−

* McQ: e4 feels 1 milestone behind where it should be (original goal was self-hosting by Christmas)

* McQ: e4 feels 1 milestone behind where it should be (original goal was self-hosting by Christmas)

* McQ: Look and feel in e4 for the SDK: Susan Franklin created some Markups in {{bug|293481}} please add constructive criticism

* McQ: Look and feel in e4 for the SDK: Susan Franklin created some Markups in {{bug|293481}} please add constructive criticism

+

** e.g. how much whitespace should be expected etc

+

** note that an e4 goal is to support multiple looks / feels

* How could AC help / e4 be promoted / early adoption?

* How could AC help / e4 be promoted / early adoption?

−

+

** McQ wants selfhosting running by Eclipsecon, thats the right time to start thinking about early adoption

−

==== git at Eclipse - current state of affairs ====

+

** It would be good to find people who build stuff on "plain e4" rather than the compatibility layer... but currently that is more realistic for standalone rcp apps (RSSOwl?)

−

* is [[Git for Committers]] still up to date with {{bug|280583}} complete for the read-only git of all of Eclipse

+

** Shape of the model should be pretty stable by now, but rest is in flux... so migrating now would be more about helping e4 than helping apps

−

* could instructions be simplified for the most common use cases:

+

** Other candidate: anybody interested in building a web based UI component (hosted in Eclipse but also in a browser) like igoogle home pages... e.g. junit tests running on server show results in something like the junit view rather than plain xml

** Legal says: In order to use the Ribbon lnf in an app, one has to sign an agreement with MS which says one is not competing with MS. Pushing that requirement on every consumer of the Platform makes this a non starter in the Platform

−

** Rebasing my branch to a new milestone

+

==== target platform docs ====

==== target platform docs ====

Line 104:

Line 96:

** CDT: Documentation for the C runtime I develop against

** CDT: Documentation for the C runtime I develop against

** RT/Equinox: Documentation for the target I develop against

** RT/Equinox: Documentation for the target I develop against

−

* Any known solutions? What are people doing today?

+

* Any known solutions? What are people doing today?

* What could be done from an architectural point of view?

* What could be done from an architectural point of view?

+

** Darin W: UA might be smart enough in terms of its webserver to look for documentation in the target rather than the host

+

** McQ: Chris G looking at a related IBM usecase... want to have a single large infocenter with docs for multiple products, but have a particular view into that

New Topics

e4 - current state of affairs

McQ: e4 feels 1 milestone behind where it should be (original goal was self-hosting by Christmas)

McQ: Look and feel in e4 for the SDK: Susan Franklin created some Markups in bug 293481 please add constructive criticism

e.g. how much whitespace should be expected etc

note that an e4 goal is to support multiple looks / feels

How could AC help / e4 be promoted / early adoption?

McQ wants selfhosting running by Eclipsecon, thats the right time to start thinking about early adoption

It would be good to find people who build stuff on "plain e4" rather than the compatibility layer... but currently that is more realistic for standalone rcp apps (RSSOwl?)

Shape of the model should be pretty stable by now, but rest is in flux... so migrating now would be more about helping e4 than helping apps

Other candidate: anybody interested in building a web based UI component (hosted in Eclipse but also in a browser) like igoogle home pages... e.g. junit tests running on server show results in something like the junit view rather than plain xml

Doug S: Ribbon IDE? Toolbar still looks very ugly on Susan's markups

Legal says: In order to use the Ribbon lnf in an app, one has to sign an agreement with MS which says one is not competing with MS. Pushing that requirement on every consumer of the Platform makes this a non starter in the Platform

target platform docs

Today, all searchable documentation is for the development host (e.g. o.e.platform.doc.isv)

When I develop against multiple target platforms, how can I access correct documentation?

Sample use cases:

Use Eclipse 3.6m4 development host but work on the R3_5_maintenance brach as target platform

WTP: Documentation for the server-side target e.g. servlets

CDT: Documentation for the C runtime I develop against

RT/Equinox: Documentation for the target I develop against

Any known solutions? What are people doing today?

What could be done from an architectural point of view?

Darin W: UA might be smart enough in terms of its webserver to look for documentation in the target rather than the host

McQ: Chris G looking at a related IBM usecase... want to have a single large infocenter with docs for multiple products, but have a particular view into that