Equinox/p2/Meetings/20081103

Agenda

• Moving the call
• Report on coverage and tests.
• M4 plan review
• Composite Repositories
  • How should we persist on disk? Existing content.xml/artifact.xml or create a new file?
  • What happens when a subrepository fails to load? How should we cache subrepositories?

Attendees

• Andrew Cattle
• Andrew Niefer
• DJ Houghton
• Jed Anderson
• Jim Miles
• John Arthorne
• Pascal Rapicault
• Scott Lewis
• Simon Kaegi
• Susan McCourt
• Tom Watson

Minutes

• Recap:
  • Relatively pleasant milestone week for M3. Do it again!

• Move the p2 dev call
  • Pascal to send a message to the dev list but in a nutshell proposes doing calls on Tuesday instead of Monday at the same time (possibly +30 minutes)

• Testing
  • Test writing marathon was again good with lots more tests written. John to re-do coverage numbers.
  • Susan provided some details around UI tests and talked a bit about automation.
  • Scott talked about transport tests and in particular proxy infrastructure. He mentioned looking at adding some filetransfer tests.
  • Pascal brought up some ideas around build tests.

• M4 Plan
  • business as usual
  • Some talk about integrating some of Genuitec's changes from their "uber patch". Jed mentioned he'd have a bettter idea where things sit next week.
  • Scott brought up possible work on repo discovery
  • Jim brought up some questions about the action contribution model (done in m3) and install handlers (help wanted - not currently planned for m4). Jim to get back to us on whether the current model for action contributions will work for his use-cases. In particular this hinges on the need for "dynamic" actions installation vs. pre-installation of actions in an installer.
  • Scott had some questions around whats changing for PDE Build in M4. Nothing currently committed to but should update plan if there are changes others should be aware of.

• Composite Sites
  • Work being done by Andrew Cattle (around for another 7 weeks)
  • One important use-case is to improve how we're handling our 3.4/3.5 sites. We're currently doing our own aggregation and management of artifacts/metadata in a "mega" site. Composite repos would allow us to have one site per build and then logicall aggregate the sites under one repo URI that would track which sites to include.
  • Some discussion around implementation decisions:
    • different repo type(?)
    • different repo sub-type(?) (see SimpleMetadataRepository)
    • re-use associate site concept(?)
    • Another useful usecase is custom categorization. Possibly supported by doing filter in repo(?)