Skip to main content
Jump to: navigation, search


< Equinox‎ | p2‎ | Meetings


  • 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


  • 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


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

Back to the top