Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox/p2/Meetings/20090504"
| Line 1: | Line 1: | ||
| − | * Javadoc? | + | ===Attendees=== |
| + | * Jeff McAffer | ||
| + | * Simon Kaegi | ||
| + | * Darin Wright | ||
| + | * Curtis Windatt | ||
| + | * Chris Aniszczyk | ||
| + | * Doug Schaefer | ||
| + | * Tom Watson | ||
| + | * Scott Lewis | ||
| + | * Susan McCourt | ||
| + | * Igor Fedorenko | ||
| + | * Henrik Lindberg | ||
| + | * Ian Bull | ||
| + | * Andrew Niefer | ||
| + | * DJ Houghton | ||
| + | * John Arthorne | ||
| + | * Pascal Rapicault | ||
| + | |||
| + | ===Javadoc=== | ||
| + | * we don't ship javadoc | ||
| + | * our APIs are provisional | ||
| + | * people want APIs to start hacking code | ||
| + | * javadoc itself is mostly not written in the code | ||
| + | * also includes errors | ||
| + | * what does "publish" mean? part of the SDK? on our web site? | ||
| + | * all platform javadoc is together in one bundle | ||
| + | * if we publish it, it would be embarassing little but would be even more embarassing to be wrong | ||
| + | * we don't need javadoc for everything to begin with | ||
| + | * <font color="red">pascal to talk to Olivier about the javadoc builder and potential issues</font> | ||
| + | * <font color="red">plan is to publish partial javadoc - does "partial" mean per package? what is the granularity?</font> | ||
| + | * make sure the API says "provisional" | ||
| + | * what about schema doc for extensions registry things? maybe action stuff but not repos, for instance. pascal to look at it | ||
| + | |||
| + | ===Eclipse RCs=== | ||
| + | * It is RC1 and not open season | ||
| + | * focused bug fixes | ||
| + | * weigh benefit versus risk | ||
| + | * don't fix things just for the sake of it | ||
| + | * focus on the big things first | ||
| + | |||
| + | ===ECF Build Contribution=== | ||
| + | * Scott co-ordinating with Henrik on error code issues | ||
| + | * will have build contributions ready by Wed 8pm (EST) during RC phase | ||
| + | * RC candidate build is on Thurs 8pm | ||
| + | |||
| + | ===Target Provisioning=== | ||
* Target platform provisioning. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=272750 Bug 272750] | * Target platform provisioning. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=272750 Bug 272750] | ||
| + | * 3.4 you download repo, extract, and add those dirs to your target def | ||
| + | * 3.5 you can add a repo as well | ||
| + | * uses a profile, create a plan and then collect and install the IUs into the profile (note this is platform specific) | ||
| + | * easier to share with team, reusable, uses bundle pool | ||
| + | * can still use delta pack in same way as you did in 3.4 | ||
| + | * people produce p2 repos as part of their build, but how are they intended to be consumed? | ||
| + | * repos are incomplete (RT repo contains only RT stuff, don't contain JRE, etc) | ||
| + | |||
| + | * original intention was for providing the repos to pde/build as repos to build against | ||
| + | * saved having to regenerate metadata | ||
| + | * we used the repo2runnable to put things in "compile against" form | ||
| + | |||
| + | * prob: the repositories are merged into the same list as you have in your install, they aren't confined to the target | ||
| + | * prob: grabbing fragments, optional pieces, and platform specific pieces | ||
| + | |||
| + | * galileo builder runs the planner once per platform config and then collects everything and then goes and grabs everything | ||
| + | |||
| + | * need to weigh and manage user expectations | ||
| + | * when they add a repo to add EMF, should they be expected to add a repo for the SDK to satisfy requirements? | ||
| + | * Help is another example... is not runnable on its own, needs other stuff | ||
| + | |||
| + | * major issues are | ||
| + | ** how to consume downloadable zips | ||
| + | ** multi-platform | ||
| + | ** inclusion of all dependencies or not | ||
Latest revision as of 16:31, 4 May 2009
Attendees
- Jeff McAffer
- Simon Kaegi
- Darin Wright
- Curtis Windatt
- Chris Aniszczyk
- Doug Schaefer
- Tom Watson
- Scott Lewis
- Susan McCourt
- Igor Fedorenko
- Henrik Lindberg
- Ian Bull
- Andrew Niefer
- DJ Houghton
- John Arthorne
- Pascal Rapicault
Javadoc
- we don't ship javadoc
- our APIs are provisional
- people want APIs to start hacking code
- javadoc itself is mostly not written in the code
- also includes errors
- what does "publish" mean? part of the SDK? on our web site?
- all platform javadoc is together in one bundle
- if we publish it, it would be embarassing little but would be even more embarassing to be wrong
- we don't need javadoc for everything to begin with
- pascal to talk to Olivier about the javadoc builder and potential issues
- plan is to publish partial javadoc - does "partial" mean per package? what is the granularity?
- make sure the API says "provisional"
- what about schema doc for extensions registry things? maybe action stuff but not repos, for instance. pascal to look at it
Eclipse RCs
- It is RC1 and not open season
- focused bug fixes
- weigh benefit versus risk
- don't fix things just for the sake of it
- focus on the big things first
ECF Build Contribution
- Scott co-ordinating with Henrik on error code issues
- will have build contributions ready by Wed 8pm (EST) during RC phase
- RC candidate build is on Thurs 8pm
Target Provisioning
- Target platform provisioning. See Bug 272750
- 3.4 you download repo, extract, and add those dirs to your target def
- 3.5 you can add a repo as well
- uses a profile, create a plan and then collect and install the IUs into the profile (note this is platform specific)
- easier to share with team, reusable, uses bundle pool
- can still use delta pack in same way as you did in 3.4
- people produce p2 repos as part of their build, but how are they intended to be consumed?
- repos are incomplete (RT repo contains only RT stuff, don't contain JRE, etc)
- original intention was for providing the repos to pde/build as repos to build against
- saved having to regenerate metadata
- we used the repo2runnable to put things in "compile against" form
- prob: the repositories are merged into the same list as you have in your install, they aren't confined to the target
- prob: grabbing fragments, optional pieces, and platform specific pieces
- galileo builder runs the planner once per platform config and then collects everything and then goes and grabs everything
- need to weigh and manage user expectations
- when they add a repo to add EMF, should they be expected to add a repo for the SDK to satisfy requirements?
- Help is another example... is not runnable on its own, needs other stuff
- major issues are
- how to consume downloadable zips
- multi-platform
- inclusion of all dependencies or not