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.
Difference between revisions of "Equinox/p2/Meetings/20081208"
(→Agenda) |
|||
(3 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
== Agenda == | == Agenda == | ||
* Plan / M4 wrap up | * Plan / M4 wrap up | ||
+ | * Testing | ||
* Support for what "type" of repository will be loaded [https://bugs.eclipse.org/bugs/show_bug.cgi?id=222251 bug# 222251] | * Support for what "type" of repository will be loaded [https://bugs.eclipse.org/bugs/show_bug.cgi?id=222251 bug# 222251] | ||
* New Collector [https://bugs.eclipse.org/bugs/show_bug.cgi?id=256355 256355] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=256411 256411] | * New Collector [https://bugs.eclipse.org/bugs/show_bug.cgi?id=256355 256355] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=256411 256411] | ||
* Interfaces for metadata types [https://bugs.eclipse.org/bugs/show_bug.cgi?id=256359 256359] | * Interfaces for metadata types [https://bugs.eclipse.org/bugs/show_bug.cgi?id=256359 256359] | ||
+ | |||
+ | == Attendees == | ||
+ | |||
+ | * Andrew Cattle | ||
+ | * Andrew Niefer | ||
+ | * Curtis Windatt | ||
+ | * Dave Stevenson | ||
+ | * DJ Houghton | ||
+ | * Doug Schaefer | ||
+ | * Henrik Lindberg | ||
+ | * Ian Bull | ||
+ | * John Arthorne | ||
+ | * Pascal Rapicault | ||
+ | * Scott Lewis | ||
+ | * Simon Kaegi | ||
+ | * Susan McCourt | ||
+ | * Tom Watson | ||
+ | |||
+ | == Minutes == | ||
+ | * Plan review | ||
+ | ** Dependency on update manager: | ||
+ | *** Need to do investigation to provide replacement concepts, but don't plan to remove UM in 3.5. | ||
+ | *** People can already run without UM if desired | ||
+ | ** Metadata authoring workflow | ||
+ | *** Some work has been done, but need to map out the vision describing how metadata goes from development time authoring, through build into deployed systems | ||
+ | ** Install handler replacement | ||
+ | *** Work has been moved to M5 | ||
+ | ** Complete integration of publisher with build | ||
+ | *** Andrew N will write up description of remaining work | ||
+ | *** Launcher branding and product publishing remains to be done | ||
+ | ** Repository association work | ||
+ | *** Some work done in M4 already ([http://bugs.eclipse.org/234213 bug 234213]) | ||
+ | *** Remaining question is whether to scope updates to a subset of available repositories | ||
+ | * Testing | ||
+ | ** Tuesday is a test pass. Pascal covering Mac. John covering Vista. DJ covering Linux. Everyone welcome to help out with testing effort | ||
+ | ** Thursday is test authoring day to focus on filling in coverage in our automated test suites | ||
+ | * Support for discovering different repository types | ||
+ | ** Need a mechanism to set order of repository type lookup | ||
+ | ** Current system only works well if there is only one type of repository at a given location | ||
+ | ** There is a current bug where a local repository containing a plugins directory can be interpreted as an extension location repository | ||
+ | * New collector work | ||
+ | ** SimplePlanner#gatherAvailableInstallableUnits currently takes all IUs in the world and stores them in an array. This is not scalable for large remote or database-backed repositories | ||
+ | ** Collector has a dual role: it holds the result of a query, but can also be subclassed for doing post-processing on the result of the query, short-circuiting the query, etc | ||
+ | ** p2 UI code has the more interesting use cases for queries/collectors - wrapping query results in UI model, etc | ||
+ | * Custom implementations of metadata objects | ||
+ | ** Want to use interfaces rather than classes for metadata API to allow for alternate implementations | ||
+ | ** Interfaces would still be specified as not to be implemented by clients | ||
+ | * Version numbers | ||
+ | ** Awaiting further review of version patch. Please read the proposal and give your feedback. |
Latest revision as of 17:33, 8 December 2008
Agenda
- Plan / M4 wrap up
- Testing
- Support for what "type" of repository will be loaded bug# 222251
- New Collector 256355 256411
- Interfaces for metadata types 256359
Attendees
- Andrew Cattle
- Andrew Niefer
- Curtis Windatt
- Dave Stevenson
- DJ Houghton
- Doug Schaefer
- Henrik Lindberg
- Ian Bull
- John Arthorne
- Pascal Rapicault
- Scott Lewis
- Simon Kaegi
- Susan McCourt
- Tom Watson
Minutes
- Plan review
- Dependency on update manager:
- Need to do investigation to provide replacement concepts, but don't plan to remove UM in 3.5.
- People can already run without UM if desired
- Metadata authoring workflow
- Some work has been done, but need to map out the vision describing how metadata goes from development time authoring, through build into deployed systems
- Install handler replacement
- Work has been moved to M5
- Complete integration of publisher with build
- Andrew N will write up description of remaining work
- Launcher branding and product publishing remains to be done
- Repository association work
- Some work done in M4 already (bug 234213)
- Remaining question is whether to scope updates to a subset of available repositories
- Dependency on update manager:
- Testing
- Tuesday is a test pass. Pascal covering Mac. John covering Vista. DJ covering Linux. Everyone welcome to help out with testing effort
- Thursday is test authoring day to focus on filling in coverage in our automated test suites
- Support for discovering different repository types
- Need a mechanism to set order of repository type lookup
- Current system only works well if there is only one type of repository at a given location
- There is a current bug where a local repository containing a plugins directory can be interpreted as an extension location repository
- New collector work
- SimplePlanner#gatherAvailableInstallableUnits currently takes all IUs in the world and stores them in an array. This is not scalable for large remote or database-backed repositories
- Collector has a dual role: it holds the result of a query, but can also be subclassed for doing post-processing on the result of the query, short-circuiting the query, etc
- p2 UI code has the more interesting use cases for queries/collectors - wrapping query results in UI model, etc
- Custom implementations of metadata objects
- Want to use interfaces rather than classes for metadata API to allow for alternate implementations
- Interfaces would still be specified as not to be implemented by clients
- Version numbers
- Awaiting further review of version patch. Please read the proposal and give your feedback.