Equinox/p2/Meetings/20081103

From Eclipsepedia

< Equinox‎ | p2‎ | Meetings
Jump to: navigation, search

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(?)