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