Equinox/p2/Meetings/20091221

Attendees

• Ian
• John
• Pascal
• Thomas H
• Henrik

Agenda

• Timetable for merging API branch into HEAD.
  • We will merge back in HEAD from the branch the week of the January 12th once the I build of this week will have been declared successful.
  • We need to talk to the PDE team to make sure that what they have in the p2 API branch is good and they will be able to merge in HEAD when we will.
  • When we will be merging back, we will not be completely done with the rework.
    • The fact of not being done is mitigated by having reduced the number of dependencies on p2 from Helios. This is done by now having as part of p2 the Mylyn discovery UI and having WTP, DTP, etc bought in having a single mechanism for install things like extensions.
    • Despite this reduced set of dependencies, most of the key types should have been moved to their final locations.
    • Key decisions:
      • Thomas H will start moving the p2 API to Java 5 with the goal of changing the key types while everybody is away
      • Thomas H and Pascal will work on using IExpression instead of IQuery
      • Package move will continue on over the next few weeks as they get ready.
  • Wrt schedule Pascal reminds that we also need to keep some time to fix up the issues that have been opened and existed before.

• Query Indexes (bug 298266)

• Mylyn discovery UI
  • We will try to bring them on board for the merge or very shortly after.

• Solver competition
  • Pascal describes the status of our participation to the solver competition organised by the EU project Mancoosi.
  • The data is very interesting because it is larger than the typical p2 repos. Some repos have more than 50,000 IUs. This has revealed some performance problems in the code of the QueryableArray where despite a hashed lookup we also had some linear lookups that were fatal.
  • The ability to fix up those performance issues is interesting when faced with large repos, and put a new perspective on the need to do work on a "smart" server. Instead we may want to have a better story for local storage of IUs as well as synchronisation with the repo content.
  • Other outcomes:
    • New optimization functions that we will be able to use to look for the best updates, manage an OSGi system that has no root (e.g. after the fact provisioning)
    • Different API to express the change request, rather than adding / removing IU. The request is expressed as a requirement which allow for ranges.
    • CUDF as a more friendly format to test the resolver