Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Equinox/p2/Meetings/20090112"

< Equinox‎ | p2‎ | Meetings
(Agenda)
(Attendees)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
== Attendees ==
 +
* Dave
 +
* Scott
 +
* Jeff
 +
* Darin
 +
* Curtis
 +
* Ian
 +
* Doug
 +
* Simon
 +
* Andrew
 +
* DJ
 +
* Pascal
 +
* Thomas H
 +
* Henrik
 +
 
== Agenda ==
 
== Agenda ==
* Matt and Eric to talk about security workflows
+
* ECF 2.1 will be in 3.4.2 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=260456]
* When do we release the Omni Version?
+
 
 
* Metadata overall story
 
* Metadata overall story
** Using and publishing metadata repos
+
** Pascal describes the story around metadata consumption. In short, ppl produces zips of p2 repositories, consumers grab those zips, put them in a special place instead of unzipping them. PDE build will "transform" the content of those zips such that they are in a "compilable against" form (e.g. unzip things that are zipped) and eventually reuse the metadata that was originally inputed.
** Reusing IUs
+
*** Bug about reusing IUs [https://bugs.eclipse.org/bugs/show_bug.cgi?id=259792]
 +
*** Bug about the transformer [https://bugs.eclipse.org/bugs/show_bug.cgi?id=260582]
 +
** The story was focused around PDE Build under the assumption that PDE UI knew about p2 profiles. However this is not the case and we may have to do some additional work in this space.
 +
 
 +
* Matt and Eric to talk about security workflows
 +
** Matt and Eric weren't there. Pascal describes the intent of the changes: improve how we present and remember certificates.
 +
 
 +
* When do we release the Omni Version? [https://bugs.eclipse.org/bugs/show_bug.cgi?id=233699]
 +
** What is the overhead? Thomas and Henrik said that the code is optimized for dealing with OSGi versions. That said Simon still is worried that  version range checks and version equals checks may cause "slowness" because they are used heavily (e.g. resolution, query).
 +
** Henrik and Thomas have agreed to run some benchmarks and report.
 +
** We want to release the patch this week, despite not having the ResolutionHelper in. However before releasing we want to verify why the End2End tests are failling on some platforms. Pascal will check on Mac with and w/o the omni version patch. DJ will do the same on linux.
 +
 
 +
* Resolver / Explanation
 +
* Jed indicates that he will have a patch ready by the end of the week that have the projector directly interface with SAT4J. The explanation work may not be in yet. The replacement for the ResolutionHelper may not be there either. Thomas H had proposed help there in the past.
 +
 
 +
* New code and coverage
 +
** During the call it is agreed that new code will have to have a coverage of 75%. This will be used as a metric to get code in.
 +
 
 +
* Progress on the Query Management and Optimization proposal [http://wiki.eclipse.org/Equinox/p2/Proposals/Query_Management_and_Optimization]
 +
** Ian recap where he is at and says that he will be ready to have all his changes in M5.
 +
** Jeff emphasizes the importance of releasing this work. Pascal wants the code to be reviewed by Susan and John.
 +
 
 +
* Install handler replacement
 +
** Henrik recap the current thinking: forking a new instance to install the handlers into.
 +
** Pascal is scared of this approach because it is unclear what needs to be contained in the new instance (which bundles, what about bundles for repo, how do you stop possible infinite recursions, etc), passing the context is not necessarily easy and the cross process communication may not be trivial. He would rather do something where the actions are installed into the profile running the installer, be it just the installer or the actual provisioned system.
 +
** Simon talks about the need to have actions (formerly install handlers) be uninstalled at the end of an install (but kept around). Objections around this are that nothing will guarantee that it will be reinstallable, and that everyone is fine having p2 with its current actions in their install, so why not have more?
 +
** Jeff reminds that Simon had proposed using the new nested framework capability. Henrik will investigate and report.

Latest revision as of 22:50, 12 January 2009

Attendees

  • Dave
  • Scott
  • Jeff
  • Darin
  • Curtis
  • Ian
  • Doug
  • Simon
  • Andrew
  • DJ
  • Pascal
  • Thomas H
  • Henrik

Agenda

  • ECF 2.1 will be in 3.4.2 [1]
  • Metadata overall story
    • Pascal describes the story around metadata consumption. In short, ppl produces zips of p2 repositories, consumers grab those zips, put them in a special place instead of unzipping them. PDE build will "transform" the content of those zips such that they are in a "compilable against" form (e.g. unzip things that are zipped) and eventually reuse the metadata that was originally inputed.
      • Bug about reusing IUs [2]
      • Bug about the transformer [3]
    • The story was focused around PDE Build under the assumption that PDE UI knew about p2 profiles. However this is not the case and we may have to do some additional work in this space.
  • Matt and Eric to talk about security workflows
    • Matt and Eric weren't there. Pascal describes the intent of the changes: improve how we present and remember certificates.
  • When do we release the Omni Version? [4]
    • What is the overhead? Thomas and Henrik said that the code is optimized for dealing with OSGi versions. That said Simon still is worried that version range checks and version equals checks may cause "slowness" because they are used heavily (e.g. resolution, query).
    • Henrik and Thomas have agreed to run some benchmarks and report.
    • We want to release the patch this week, despite not having the ResolutionHelper in. However before releasing we want to verify why the End2End tests are failling on some platforms. Pascal will check on Mac with and w/o the omni version patch. DJ will do the same on linux.
  • Resolver / Explanation
  • Jed indicates that he will have a patch ready by the end of the week that have the projector directly interface with SAT4J. The explanation work may not be in yet. The replacement for the ResolutionHelper may not be there either. Thomas H had proposed help there in the past.
  • New code and coverage
    • During the call it is agreed that new code will have to have a coverage of 75%. This will be used as a metric to get code in.
  • Progress on the Query Management and Optimization proposal [5]
    • Ian recap where he is at and says that he will be ready to have all his changes in M5.
    • Jeff emphasizes the importance of releasing this work. Pascal wants the code to be reviewed by Susan and John.
  • Install handler replacement
    • Henrik recap the current thinking: forking a new instance to install the handlers into.
    • Pascal is scared of this approach because it is unclear what needs to be contained in the new instance (which bundles, what about bundles for repo, how do you stop possible infinite recursions, etc), passing the context is not necessarily easy and the cross process communication may not be trivial. He would rather do something where the actions are installed into the profile running the installer, be it just the installer or the actual provisioned system.
    • Simon talks about the need to have actions (formerly install handlers) be uninstalled at the end of an install (but kept around). Objections around this are that nothing will guarantee that it will be reinstallable, and that everyone is fine having p2 with its current actions in their install, so why not have more?
    • Jeff reminds that Simon had proposed using the new nested framework capability. Henrik will investigate and report.

Back to the top