Equinox/p2/Meetings/20081208

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
• 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.