|
|
| (36 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| − | = Week of 20080107 =
| + | #REDIRECT [[Equinox/p2/Meetings]] |
| − | == Agenda ==
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | | + | |
| − | = Week of 20071217 =
| + | |
| − | == Agenda ==
| + | |
| − | | + | |
| − | * discuss M5 plan
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * Andrew Overholt
| + | |
| − | * Dave Stevenson
| + | |
| − | * Jim Miles
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Scott Lewis
| + | |
| − | * Simon Kaegi
| + | |
| − | * Stefan Liebig
| + | |
| − | * Susan McCourt
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | * Susan: updated M5 plan with her stuff; no new big stuff; will focus on polish and performance
| + | |
| − | | + | |
| − | * John working on finishing off transition to using URLs; Stefan may help with this
| + | |
| − | | + | |
| − | * Scott noted that ECF just added support for scp support for File.put (?) which may be of interest to directly publishing repos and also mentioned also that ECF support for using platform proxy preference made it into recent build; will work with DJ on consuming that build
| + | |
| − | | + | |
| − | * Andrew: Shared Install Plan done; will continue experimenting with implementation and report progress on list; also finishing up simpleconfigurator tests with Tom
| + | |
| − | | + | |
| − | * Stefan focusing on increasing robustness; will also investigate https and its integration
| + | |
| − | | + | |
| − | * Simon: looking at what DJ and Dave are doing with integration of update manager compatibility; reconciler -> startup sequence
| + | |
| − | | + | |
| − | * Pascal: going to talk to sat4j author; looking into outstanding bugs; going to talk to Tim about outstanding downloadmanager questions
| + | |
| − | | + | |
| − | * Jim: has free time this week and will look at install handler stuff and multi-user use cases; has some issues with touchpoints and phases that he will document
| + | |
| − | | + | |
| − | What do we need to have to be "ready" to become a part of the SDK?
| + | |
| − | * robustness
| + | |
| − | * some level of support for installing from update sites
| + | |
| − | * JRE metadata generation
| + | |
| − | | + | |
| − | Action item: look into bugs you opened and flesh them out, re-validate, mark if you intend to fix for M5, take action on M4 ones
| + | |
| − | | + | |
| − | Vacation:
| + | |
| − | | + | |
| − | * Dave: now -> 2 January
| + | |
| − | * Susan: now -> 2 January
| + | |
| − | * John: now -> 2 January
| + | |
| − | * DJ: now -> 7 January
| + | |
| − | * Jeff: 19 December -> 2 January
| + | |
| − | * Stefan: 20 December -> 7 January
| + | |
| − | * Pascal: 20 December -> 9 January
| + | |
| − | * Andrew: 24 December -> 2 January
| + | |
| − | * Simon: 24 December -> 2 January
| + | |
| − | * Jim: 24 December -> 7 January
| + | |
| − | | + | |
| − | = Week of 20071210 =
| + | |
| − | == Agenda ==
| + | |
| − | | + | |
| − | * M4 milestone week
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * Andrew Overholt
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * Jim Miles
| + | |
| − | * John Arthorne
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Simon Kaegi
| + | |
| − | * Stefan Liebig
| + | |
| − | * Susan McCourt
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | * We're going to populate a test repository with various versions of the SDK for testing purposes during the test pass.
| + | |
| − | * Be sure to communicate frequently on equinox-dev mailing list, and in bugzilla as issues arise.
| + | |
| − | * Please add manual scenarios to [[Equinox p2 tests]] for things that can't be tested with automatic tests
| + | |
| − | * Update compatibility: Work in progress, not sure what will be ready for M4
| + | |
| − | * Installing features: Work in progress, running into director/resolution issues with binding configuration units.
| + | |
| − | * Drop in reconciler: We won't start it eagerly on startup. For M4 it will be started by exemplarysetup as soon as the agent is started. We'd like to avoid putting p2 into the critical performance path on startup.
| + | |
| − | * UI: create "Uncategorized" node in available features list.
| + | |
| − | * Shared install: working on refining [[Equinox p2 Shared Install Plan]].
| + | |
| − | | + | |
| − | = Week of 20071203 =
| + | |
| − | == Agenda ==
| + | |
| − | * Do we want some improvement on the self-hosting?
| + | |
| − | * How do we test artifacts in multiple shapes (pack200, delta, etc.)? Do we want to produce them for M4?
| + | |
| − | * Think about additional manual tests scenarios.
| + | |
| − | * Integration of the drop-in reconciler in the build.
| + | |
| − | * M4 Status
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * DJ Houghton
| + | |
| − | * Jim Miles
| + | |
| − | * John Arthorne
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Scott Lewis
| + | |
| − | * Simon Kaegi
| + | |
| − | * Stefan Liebig
| + | |
| − | * Susan McCourt
| + | |
| − | * Andrew Overholt
| + | |
| − | * Dave Stevenson
| + | |
| − | * Jeff McAffer
| + | |
| − | * Ted Habeck
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | * Dropin Reconciler
| + | |
| − | ** watches the /dropins folder in an eclipse install for changes at startup and synchronized add/removes with the current profile
| + | |
| − | ** Add it to End-user UI for M4
| + | |
| − | ** Consider breaking out in later Milestones along with other components
| + | |
| − | ** Needs to be started after exmplary startup
| + | |
| − | | + | |
| − | * ArtifactRepository.getOuputStream
| + | |
| − | ** brief discussion around removing ArtifactRequest from the method signature and consequences
| + | |
| − | | + | |
| − | * Selfhosting generator
| + | |
| − | ** Bundle that will generate metadata/artifact repo when current profile is null
| + | |
| − | ** For m4
| + | |
| − | ** recovery mechanism (e.g. remove p2 folder)
| + | |
| − | ** also useful for testing
| + | |
| − | ** potentially limits need or at least provides alternative to selfhosting pde integration
| + | |
| − | | + | |
| − | * Memory overhead in Repositories
| + | |
| − | ** John using a profiler to determine where we're being wasteful in terms of metadta caches.
| + | |
| − | ** Also working on making repositorymanagers URL/URI based in terms of repo identifier
| + | |
| − | ** goal is to load repos on demand as opposed to aggrssively
| + | |
| − | ** some questions around flushing still to be answered
| + | |
| − | | + | |
| − | * Quick Status updates:
| + | |
| − | ** DJ doing work on integration with filtering mechanisms in platform.xml using directory watcher
| + | |
| − | ** Dave doing work on metadata and artifact generation as well as modifications to platform.xml
| + | |
| − | ** Susan primarily looking at rollback UI
| + | |
| − | ** Andrew looking at reconfiguration and split bundles
| + | |
| − | | + | |
| − | * DownloadManager / Strategies
| + | |
| − | ** Pascal identified some difference between maynstall and p2
| + | |
| − | ** Some interesting areas mentioned: multi-threaded download, recovery, proxy api support
| + | |
| − | ** Scott looking at proxt api
| + | |
| − | | + | |
| − | * Artifact Shape
| + | |
| − | ** Pack200 is most likely target for m4
| + | |
| − | ** possibly make a pack200 artifact repo available
| + | |
| − | | + | |
| − | * Profile Change Events
| + | |
| − | ** A few changes to simplify listening for profile changes
| + | |
| − | ** transactional handling of property change events
| + | |
| − | ** M4 will target improvements during sizing phase, support for property change event after a commit, and basic support for doing edit work on a Profile copy
| + | |
| − | | + | |
| − | * Manual Tests Scenarios
| + | |
| − | ** Think about additional tests
| + | |
| − | ** dropins test seems like a good candidate
| + | |
| − | | + | |
| − | = Week of 20071126 =
| + | |
| − | == Agenda ==
| + | |
| − | * Bundle pooling, how does this get surfaced to the user?
| + | |
| − | * Should PDE set p2 data location on launch of target platform / JUnit test.
| + | |
| − | * M4 status, 2 weeks before warm up build
| + | |
| − | ** How are we doing wrt testing / integration of artifact descriptor choice
| + | |
| − | ** GC
| + | |
| − | ** Category generation
| + | |
| − | * Are all the bundles being built?
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * Andrew Overholt
| + | |
| − | * Darin Wright
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * Jeff McAffer
| + | |
| − | * John Arthorne
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Susan McCourt
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | * Simple installer overview
| + | |
| − | ** We are considering shipping a simple Java-based installer that would allow a user to install a product either in the old 3.3 standalone shape, or using a shared p2 data area.
| + | |
| − | ** Less emphasis in 1.0 on providing tools to manage multiple profiles (admin UI style tools)
| + | |
| − | ** We need to handle the case where a profile is moved on disk.
| + | |
| − | ** More generally we need to map out the use cases for how users will manage apps installed with the installer.
| + | |
| − | * Setting p2 data location in PDE launches
| + | |
| − | ** We should set the p2 data location to be under the configuration directory, if not already specified.
| + | |
| − | * Performance
| + | |
| − | ** Done some simple memory optimizations
| + | |
| − | ** We are still creating lots of Strings and Versions
| + | |
| − | ** Would like to move entirely to factory methods to allow for further optimizations to be made transparently
| + | |
| − | * Update manager compatibility
| + | |
| − | ** General model is to let old update manager do its thing, and p2 watches what it does and updates p2 data accordingly.
| + | |
| − | ** Use directory watcher to watch plugins/ directory, platform.xml, etc
| + | |
| − | | + | |
| − | = Week of 20071119 =
| + | |
| − | == Agenda ==
| + | |
| − | * We've started doing changes that make use of functionality in 3.4. Is this decision conscious or do we want to maintain some degree of compatibility with 3.3.x. If so, are there any changes we should maybe be doing in 3.3.2?
| + | |
| − | * Capabilities vs Properties. What are the rule to use one or the other?
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * Allan Godding
| + | |
| − | * Andrew Overholt
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * John Arthorne
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Simon Kaegi
| + | |
| − | * Susan McCourt
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | * Should we move to 3.4 code (and hence no longer be compatible with 3.3.x)
| + | |
| − | ** Difficult for UI code, since it has many dependencies. Easier for low level stuff because we have very few external dependencies
| + | |
| − | ** For now we will target 3.4, but try to keep the low level (non-UI) p2 code on 3.3.x where possible (in case requirement comes up in the future for running against 3.3.x)
| + | |
| − | | + | |
| − | * When to use a property vs. a provided capability
| + | |
| − | ** The question arose last week of when to use a provided capability on an IU versus a property. There are cases where we have added capabilities just for the convenience of being able to use IQueryable
| + | |
| − | ** Should only use a provided capability if we envision another IU having a required capability to match it. I.e., only use it for resolution.
| + | |
| − | ** We can easily add support to IQueryable for querying against IU properties if needed
| + | |
| − | | + | |
| − | * Resolver
| + | |
| − | ** p2 has a resolver that is used to match provided capability with required capabilities at install-time. Currently we have a relatively naive resolver that does not always find the best solution
| + | |
| − | ** Pascal is investigating replacing our simple resolver with a real [http://en.wikipedia.org/wiki/Boolean_satisfiability_problem SAT] solver. [http://www.sat4j.org/ SAT4J] is currently being considered. There are legal and other process issues to work out to see if we can get this code into p2.
| + | |
| − | | + | |
| − | * Garbage collection
| + | |
| − | ** Difficult to run asynchronously because it could garbage-collect newly fetched IUs that have not yet been installed.
| + | |
| − | ** Initially gc will eagerly run after an uninstall has occurred
| + | |
| − | ** Likely need some easy way to enable/disable it in the short term as we fine-tune the behaviour.
| + | |
| − | | + | |
| − | * PDE now has basic support for p2. You can now use a p2-provisioned Eclipse as your PDE target platform. Now there's '''really''' no excuse not to be self-hosting on a p2-provisioned SDK.
| + | |
| − | | + | |
| − | = Week of 20071112 =
| + | |
| − | == Agenda ==
| + | |
| − | * Robustness
| + | |
| − | * Coding practices
| + | |
| − | ** logging / debugging / NLS / Exception handling
| + | |
| − | * JBdiff test problem
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * DJ Houghton
| + | |
| − | * Jim Miles
| + | |
| − | * John Arthorne
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Scott Lewis
| + | |
| − | * Simon Kaegi
| + | |
| − | * Stefan Liebig
| + | |
| − | * Susan McCourt
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | * Stefan: Trying to track down JBdiff test problem. Tests don't fail for him, but they fail for others.
| + | |
| − | * Susan: Lots of bug fixing,
| + | |
| − | * John: Working on cleaning up and simplifying APIs
| + | |
| − | * DJ: Looking into backwards compatibility with update manager
| + | |
| − | * Pascal:
| + | |
| − | ** Talking with Andrew Niefer about integration of PDE Build with p2
| + | |
| − | ** Investigating requirements for Ganymede release train.
| + | |
| − | ** Revised 1.0 technical features list
| + | |
| − | * Simon: Working on directory watcher.
| + | |
| − | ** Issue of metadata/artifact repositories being global, but for a given operation we may only want to operate on a subset of repositories
| + | |
| − | | + | |
| − | Coding practices:
| + | |
| − | * Need to start fixing up warnings in the code, particularly NLS warnings
| + | |
| − | * We need to be consistently logging exceptions, no more "TODO: Auto-generated catch block"
| + | |
| − | * Add trace options to help with diagnosis of problems
| + | |
| − | * Taxonomy of error codes so that the UI can show a user-friendly message in case of failure.
| + | |
| − | | + | |
| − | = Week of 20071105 =
| + | |
| − | == Agenda ==
| + | |
| − | * M3 retrospective
| + | |
| − | * 1.0 plan discussion
| + | |
| − | * M4 plan discussion
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * Allan Godding
| + | |
| − | * Andrew Overholt
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * Jeff McAffer
| + | |
| − | * John Arthorne
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Scott Lewis
| + | |
| − | * Simon Kaegi
| + | |
| − | * Susan McCourt
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | === M3 restrospective ===
| + | |
| − | * The team need to be in closer contact during the test pass.
| + | |
| − | * We need to be more disciplined about what we commit to ensure stabilization.
| + | |
| − | * Need better logging and debug info to help us understand what is going on.
| + | |
| − | * Need to run the manual tests regularly throughout the week.
| + | |
| − | * The production of repos and the agent download was painful. This was caused by our integration into the build and the subtle setup differences. There is nothing much we can do about it, except maybe *not* being integrated with the SDK build since this limit our ability to do changes.
| + | |
| − | | + | |
| − | === 1.0 plan discussion ===
| + | |
| − | * Is an Installer in the scope of the deliverable? What would we provide? Where would it be used? We all agree that it would be nice to have such an installer, however it would just be an exemplary application for the SDK only. The creation of a full blown installer would be left to the EPP folks. Jeff to talk to them.
| + | |
| − | * Ganymede, what is the plan for integration? We will be working with Bjorn and investigate the scripts to find the least perturbing way to produce p2 for Ganymede. https://bugs.eclipse.org/bugs/show_bug.cgi?id=208648.
| + | |
| − | | + | |
| − | === M4 plan discussion ===
| + | |
| − | * Review the plan. Scott and Stefan to work with Tim for the integration of the download strategies.
| + | |
| − | | + | |
| − | = Week of 20071029 =
| + | |
| − | == Agenda ==
| + | |
| − | | + | |
| − | * M3 Status: what's left for M3?
| + | |
| − | * M3 testing
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * Andrew Overholt
| + | |
| − | * Darin Wright
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * Jeff McAffer
| + | |
| − | * John Arthorne
| + | |
| − | * Simon Kaegi
| + | |
| − | * Susan McCourt
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | * There is a set of [[Equinox p2 tests]] that we can use for manual testing
| + | |
| − | * Pascal is investigating one last fix relating to paths in bundles.txt file.
| + | |
| − | * We should be able to upgrade across I-builds this week, starting with Monday noon EST build
| + | |
| − | * We can start discussing M4 plan later this week.
| + | |
| − | * Andrew/DJ will test Linux, John will test Vista, Pascal will test Mac.
| + | |
| − | * The artifact repository that we publish is not currently optimized (pack200). It's too late to integrate this with the build process, but we will investigate setting up an optimized artifact repository manually for testing purposes.
| + | |
| − | * Should we continue to publish zipped artifact/metadata repositories? Explore writing a simple mirroring application that can mirror an entire metadata/artifact repository to another location.
| + | |
| − | | + | |
| − | = Week of 20071022 =
| + | |
| − | == Agenda ==
| + | |
| − | * M3 Status: M3 is next week
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * Andrew Overholt
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * Jim Miles
| + | |
| − | * John Arthorne
| + | |
| − | * Simon Kaegi
| + | |
| − | * Stefan Liebig
| + | |
| − | * Susan McCourt
| + | |
| − | * Pascal Rapicault
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | Updating across I-Builds:
| + | |
| − | * still need a strategy for updateable metadata
| + | |
| − | * not ready for M3
| + | |
| − | | + | |
| − | PDE Targets based on bundles.txt:
| + | |
| − | * waiting for a fix in PDE. Pascal to follow-up with Darren
| + | |
| − | | + | |
| − | MultiOS metadata:
| + | |
| − | * work in progress, still targetting M3
| + | |
| − | | + | |
| − | UI:
| + | |
| − | * in good shape for M3
| + | |
| − | * Polishing workflows
| + | |
| − | | + | |
| − | Shared Install:
| + | |
| − | * Andrew to run some integration tests and then submit patch/zip
| + | |
| − | * still some usecases around preferences for reconcilitation to iron out.
| + | |
| − | | + | |
| − | XStream replacement:
| + | |
| − | * Interesting problems that we were inadvertently solving with XStream around the RepositoryManager and identification and subsequent serialization of RepositoryTypes
| + | |
| − | * Some M3 timing issues to work out. We may want to push hard for this one.
| + | |
| − | | + | |
| − | Planner:
| + | |
| − | * Done and seems to be well liked.
| + | |
| − | | + | |
| − | = Week of 20071015 =
| + | |
| − | == Agenda ==
| + | |
| − | * M3 Status, 2 weeks away
| + | |
| − | * Engine, what is the replacement for Javascript?
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * Andrew Overholt
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * Jeff McAffer
| + | |
| − | * Jim Miles
| + | |
| − | * John Arthorne
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Scott Lewis
| + | |
| − | * Simon Kaegi
| + | |
| − | * Susan McCourt
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | Update on Engine work:
| + | |
| − | * Javascript has been removed from the Engine. The current replacement is a very simple declarative language of the form "ActionName(Variable1:Value1,Variable2:Value2,...)".
| + | |
| − | * Another option to consider is a more "REST-style" approach of a markup language that describes the desired end state rather than the actions required to get to that state.
| + | |
| − | * ProvisioningAction API is in a state where people can start to implement actions, with the caveat that there will likely be further refinements to the API over M3/M4.
| + | |
| − | | + | |
| − | Discussion of the interaction of p2 with Linux RPM:
| + | |
| − | * May have scenarios where RPM is driving the install, and it will call out to p2 to update profiles, etc.
| + | |
| − | * Conversely, in p2 driven installs, may require an RPM action that calls out from p2 to update the RPM database.
| + | |
| − | * Andrew is currently thinking that Linux distros will favour RPM-driven install that calls out to p2 as needed.
| + | |
| − | | + | |
| − | Undo/Rollback/Become:
| + | |
| − | * There are different flavors of "undo"
| + | |
| − | ** Undo at UI level of lightweight actions such as add repo, etc. Maintains an undo stack. Not persisted across sessions.
| + | |
| − | ** Rollback for cases where an engine operation fails part way through. This is an internal engine concept that is not exposed for clients to invoke it.
| + | |
| − | ** Become: Make my profile look like X
| + | |
| − | ** Revert: Director level API to get back to an older profile state (could be implemented by using become).
| + | |
| − | | + | |
| − | Governor:
| + | |
| − | * Initial exploration of governor API. Please chime in with comments ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=205068 Bug 205068])
| + | |
| − | | + | |
| − | Provisioning workshop:
| + | |
| − | * There was a provisioning symposium at [http://eclipsesummit.org/summiteurope2007/ Eclipse Summit Europe 2007].
| + | |
| − | * Jeff gave an overview of p2 design and a short demo of current functionality (slides to be available soon)
| + | |
| − | * Realization that there may be overlap with ongoing work in STP (SOA Tools Platform) and WTP (Web Tools Platform).
| + | |
| − | | + | |
| − | ECF update:
| + | |
| − | * ECF has added API for partial downloads over HTTP (given a byte range).
| + | |
| − | * Should consume ECF 1.2 release after they ship this week
| + | |
| − | * We will have a platform-ECF codependency in the Ganymede release train (last minute fixes in ECF could now require platform rebuilds).
| + | |
| − | | + | |
| − | = Week of 20071008 - Thanksgiving Day in Canada=
| + | |
| − | == Agenda ==
| + | |
| − | *M3 Status
| + | |
| − | *Recap on entry points - Susan
| + | |
| − | *Eliminating XStream - Dave
| + | |
| − | *Other topics
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | * Ted Habeck
| + | |
| − | * Jim Miles
| + | |
| − | * Susan McCourt
| + | |
| − | * Dave Stevenson
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | === M3 Status ===
| + | |
| − | Jim waiting for touchpoint API to stabilize before working on touchpoints. (Dave thinks that) Simon will contribute action contribution changes this week.
| + | |
| − | | + | |
| − | Susan recapped entry points. Should a user name what is installed? override provided names? Decision: Create an entry point for every top-level group selected. Just copy name, etc. Then becomes a UI facet only. But needed Director API change. What about web installs? Still need to record in profile, so not UI only. Two distinct problems: UI display groups to used; providing different versions. Keep solutions different. Director will mark roots in profile. API at Oracle level is more difficult.
| + | |
| − | | + | |
| − | = Week of 20071001 =
| + | |
| − | == Agenda ==
| + | |
| − | *M3 Plan recap
| + | |
| − | *Updates from the Equinox Summit
| + | |
| − | *Entry points
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | * Darin Wright
| + | |
| − | * Curtis Windatt
| + | |
| − | * Dave Stevenson
| + | |
| − | * Jeff McAffer
| + | |
| − | * Jim Miles
| + | |
| − | * John Arthorne
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Simon Kaegi
| + | |
| − | * Susan McCourt
| + | |
| − | * Tim Webb
| + | |
| − | * Stefan Liebig
| + | |
| − | * Scott Lewis
| + | |
| − | * DJ Houghton
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | === M3 Planning ===
| + | |
| − | * M3 about defining a final shape for things
| + | |
| − | * quick recap of plan items see [[Equinox p2 Plan]] items for M3
| + | |
| − | * We want to be in the position to self-host between integration builds
| + | |
| − | * We're integrated with the main build process now. Pascal to tag p2 projects for integration builds.
| + | |
| − | * Jim and Dave ready to work on NativeTouchpoints
| + | |
| − | * Dave interested in looking at replacing XStream
| + | |
| − | | + | |
| − | === Updates from the Equinox Summit ===
| + | |
| − | * Governor shapes context of an install - Tim to add some API info (Some security context?)
| + | |
| − | * Discussion around Transport support for cancel and resume -- being worked on
| + | |
| − | * Need discussion on mailing list for Touchpoint Actions, Phases, replacement for JavaScript
| + | |
| − | * Need to consider commands infrastructure. IUndoableOperations seem good fit for touchpoint actions.
| + | |
| − | * Update on work on ProcessingSteps -- good shape. Fully in this week.
| + | |
| − | | + | |
| − | === Entry Points ===
| + | |
| − | | + | |
| − | Currently there are a number of concerns that entry points seek to address:
| + | |
| − | | + | |
| − | * Distinguish what the user selected to install, versus what got installed indirectly
| + | |
| − | * Helps in deciding what to update automatically
| + | |
| − | * Helpful when the user needs to be prompted to make decisions later on, it can be expressed in terms of the IUs that the user chose to install.
| + | |
| − | * Grouping of related IUs together ("C tools" to group together "CDT" and "Autoconf tools").
| + | |
| − | * Renaming of what was installed to something more familiar to user (nickname)
| + | |
| − | | + | |
| − | Problems:
| + | |
| − | * Obscure the names of the IUs that were installed (Feature name changes when it goes from "Available Features" to "Installed Features" tabs).
| + | |
| − | * There is a version numbering problem when IUs are grouped together
| + | |
| − | | + | |
| − | Should the user be prompted when installing a new feature requires updates to features they already have installed? Should they only be prompted if entry points were modified, but not if an upgrade is required to something that was only installed indirectly?
| + | |
| − | | + | |
| − | Don't want to force the user to answer difficult questions: "Installing X requires updating Y. Continue?" There are ways to avoid putting this in the user's face, for example have a "Preview" or "Details" button that allows the power user to see what's happening, without forcing all users to make a decision.
| + | |
| − | | + | |
| − | Direction for M3:
| + | |
| − | * Entry points are just a flag to distinguish what the user chose to install from things installed indirectly.
| + | |
| − | * The concept is purely internal, and no new concept/metaphor is needed in the UI
| + | |
| − | * Grouping is a separate concern that we can add independently from entry points if the need arises (not for M3).
| + | |
| − | * We need some more exploration to decide exactly how categories will work and their relationship to entry points
| + | |
| − | | + | |
| − | === Metadata repo categories ===
| + | |
| − | * Producer/consumer problem with category definition
| + | |
| − | * How to merge categories when multiple repositories are being browsed
| + | |
| − | | + | |
| − | = Week of 20070924 =
| + | |
| − | The weekly meeting was canceled due to the [[Equinox Summit 2007]]. See [[Equinox Summit 2007 Results]] for discussion minutes related to p2.
| + | |
| − | | + | |
| − | = Week of 20070917 =
| + | |
| − | == Agenda ==
| + | |
| − | * M2 -5, what are we missing, what are the actual delivery?
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * Andrew Overholt
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * Jeff McAffer
| + | |
| − | * Jim Miles
| + | |
| − | * John Arthorne
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Simon Kaegi
| + | |
| − | * Susan McCourt
| + | |
| − | * Ted Habeck
| + | |
| − | * Tim Webb
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | === Repository API Update ===
| + | |
| − | Large batch of changes to repository APIs and implementation has been released. This includes new processing step support in the artifact repository. API between metadata and artifact repository has been harmonized. Repository URLs for local repositories now refer to the root directory, not the artifact.xml or content.xml file (those file names are an implementation detail). Jeff hopes to
| + | |
| − | get pack200 support working for M2 as proof of concept for processing steps.
| + | |
| − | | + | |
| − | === 3.4 M2 status ===
| + | |
| − | * DJ is close to getting relative paths working, so we don't need to hard-code agent path, etc. Need to figure out the story for how touchpoints contribute actions. Would like to add more engine tests for M2.
| + | |
| − | * Andrew will have a patch ready soon for shared install support
| + | |
| − | * Simon has released initial cut of new Engine API. Working on transaction support - rollback/undo.
| + | |
| − | * Some minor bugs in UI to sort out, but overall in good shape.
| + | |
| − | | + | |
| − | What do we want to package for M2?
| + | |
| − | * We want to make available the prototype end user UI as well as the admin UI.
| + | |
| − | * Could just include the end-user UI in the admin UI for M2 - showcase example is to use the end user UI to update bundles in the admin UI RCP application.
| + | |
| − | * Deliver for M2: Generate metadata for Eclipse update site. Be able to install the SDK using the bundle content that is already in the Eclipse update site. Also generate metadata/artifacts for p2 bundles, and zip file for agent RCP application.
| + | |
| − | | + | |
| − | = Week of 20070910 =
| + | |
| − | == Agenda ==
| + | |
| − | * Artifact key format: should it be a hash, or a set of strings like it is today?
| + | |
| − | * Self hosting: who is running in self hosting mode, is it stable/working, when should one bother to run it (Susan)
| + | |
| − | * Reconciler for shared install: what object to use as the "shared" profile? (Tim)
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Simon Kaegi
| + | |
| − | * John Arthorne
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * Tim Webb
| + | |
| − | * Dennis Vaugn
| + | |
| − | * Ted Habeck
| + | |
| − | * Susan McCourt
| + | |
| − | * Andrew Overholt
| + | |
| − | * Jeff McAffer
| + | |
| − | * James Miles (Jim)
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | === Reconciler / Shared Install ===
| + | |
| − | * Main issue is reconciliation at startup
| + | |
| − | * Some discussion around treating Profile as an IU (or at least a mechanism to serialize a Profile as an IU)
| + | |
| − | * Shared portion is definitive.
| + | |
| − | | + | |
| − | === Become ===
| + | |
| − | * Some discussion on difference between "become" and "flush and install of toplevel IU".
| + | |
| − | * "become" should fail if the IU is not a profile.
| + | |
| − | | + | |
| − | === Self Hosting ===
| + | |
| − | * limited use (Jeff and Susan) but eventually there should be more use.
| + | |
| − | * When metada format changes a flush of existing metadata is required.
| + | |
| − | * Potential problems around restoring persistent info. DJ to look at adding persistentce to repos added to the managers.
| + | |
| − | | + | |
| − | === Artifact Key ===
| + | |
| − | * Ultimately unresolved and still requires further discussion.
| + | |
| − | * Is the Key a true opaque URI? How can we do mappings from the Key to the actual resource in a repository.
| + | |
| − | | + | |
| − | = Week of 20070903 =
| + | |
| − | == Agenda ==
| + | |
| − | * Handling of fragments: there are fragments that are mandatory (e.g. SWT), fragments that are recommended (e.g. org.eclipse.core.filesystem ones) and fragments that are optional (e.g. the ant.optional.junit obtained from CDT). How can we distinguish between these fragments?
| + | |
| − | * Event Admin, should we use it or not (https://bugs.eclipse.org/bugs/show_bug.cgi?id=184021)?
| + | |
| − | * 3 weeks from M2, where are we?
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Simon Kaegi
| + | |
| − | * James Miles (Jim)
| + | |
| − | * Stefan Liebig
| + | |
| − | * John Arthorne
| + | |
| − | * Susan McCourt
| + | |
| − | * Dave Stevenson
| + | |
| − | * DJ Houghton
| + | |
| − | * Jeff McAffer
| + | |
| − | * Andrew Overholt
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | === Engine API ===
| + | |
| − | * Recap of Engine API discussion that was held after the call
| + | |
| − | * API changes in place by end of next week
| + | |
| − | | + | |
| − | === EventAdmin discussion ===
| + | |
| − | * We would use it only as a backing implementation
| + | |
| − | * Continue using our own APIs Event Types e.g. we would not use the EventAdmin API directly
| + | |
| − | * Events destined for a particular topic should be of one type so that we avoid instanceof checks
| + | |
| − | | + | |
| − | === Fragments optional vs. requirement ===
| + | |
| − | * Cardinality problem e.g. SWT requires at least one (or perhaps exactly one) fragment to provide native integration
| + | |
| − | * Another examples are the NL case, filesystem
| + | |
| − | * Is there a generic mechanism to describe these?
| + | |
| − | * Filters might be a way to support this. The "host" would have to specify the "must" requirement.
| + | |
| − | * Decision types: "must", "should", "may", "not?" -- no nots seemed to be consensus
| + | |
| − | * There is nothing specific to fragments with this problem. e.g. it applies to the establishing of "any" relationship between IUs
| + | |
| − | | + | |
| − | = Week of 20070827 =
| + | |
| − | == Agenda ==
| + | |
| − | * Entry points and profiles, those higher-order level IUs we need to be able to manipulate
| + | |
| − | * Engine what is the API? How do we modify Profiles?
| + | |
| − | * Transactions, how pervasive are they, how are they performed? What do we need?
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Jeff McAffer
| + | |
| − | * Simon Kaegi
| + | |
| − | * James Miles (Jim)
| + | |
| − | * Andrew Overholt
| + | |
| − | * Timothy Webb (Tim)
| + | |
| − | * Stefan Liebig
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | === Engine API and Transactionality ===
| + | |
| − | * We discussed the change in model for how changes are applied to a Profile. Instead of one operation and many operands we now use many self contained operations that apply to a single profile.
| + | |
| − | * Early discussion of how we can create a Session to encapsulate a transaction.
| + | |
| − | * Phases and operations and how they relate were talked about. One thing we have to be careful about is mixing up the use of the Engine API with the Director API.
| + | |
| − | * Various ideas around using operation where we run a partial set of phases.
| + | |
| − | * Pascal, Jeff, Jim, and Simon to discuss further and update this page later.
| + | |
| − | * (Update) Key findings:
| + | |
| − | ** Install, Uninstall, Update operations for now.
| + | |
| − | ** Fixed set of phases
| + | |
| − | ** Phases are executed _breadth_ wise
| + | |
| − | ** Session is created from Engine and is used to create a transactional scope.
| + | |
| − | | + | |
| − | === Entry Points ===
| + | |
| − | * Entry Points are an encapsulation of the IUs installed at the director level
| + | |
| − | * There are tough problems around handling of entry points are IUs that group others. Shallow vs. deep search for updates.
| + | |
| − | * Discussion around if Profiles can be treated as IUs. Key use cases include the desire for one developer to use the same profile as another.
| + | |
| − | | + | |
| − | === Naming ===
| + | |
| − | * Candidates: QM, Hive, Provo, p2, Phoenix
| + | |
| − | * p2 won. Renaming can be done post M2 -- the day after preferably.
| + | |
| − | | + | |
| − | = Week of 20070820 =
| + | |
| − | == Agenda ==
| + | |
| − | * We need a lot of events, some are core to the functioning of the system, others are to help drive the UI. Currently we have our own event bus. Should we migrate to the osgi event service?
| + | |
| − | * Related to events, we need some event generation guidelines. See the concerns raised in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=199806 bug 199806].
| + | |
| − | * Naming. We have had some discussion around the naming of the work we are doing. Currently it is "The Equinox Provisioning support" or some such. This is very cumbersome for discussions, presentations, documents, ... The package name we've been using is o.e.equinox.prov.*. Before we get too too far we need a real name that we can live with through graduation. By the time of the meeting hopefully we will have had some discussion on the mailing list and be able to conclude with a decision.
| + | |
| − | * Carried over from last week's agenda: shared install
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | * John Arthorne
| + | |
| − | * DJ Houghton
| + | |
| − | * Simon Kaegi
| + | |
| − | * Susan McCourt
| + | |
| − | * James Miles (Jim)
| + | |
| − | * Andrew Overholt
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Thomas Watson
| + | |
| − | * Timothy Webb (Tim)
| + | |
| − | | + | |
| − | == Meetings ==
| + | |
| − | | + | |
| − | === Naming ===
| + | |
| − | | + | |
| − | The naming discussion was deferred because Jeff McAffer, who proposed the item, was not present
| + | |
| − | | + | |
| − | === Event handling ===
| + | |
| − | * The OSGi event service is not currently included in the SDK, so we would need to add it. Adding a listener requires registering a service.
| + | |
| − | * Could add our own event API and use Equinox service as an implementation detail
| + | |
| − | * Want to be able to batch fine-grained events
| + | |
| − | * Concurrency issues, syncExec into UI thread, locking, etc
| + | |
| − | * John to take a look at OSGi event API
| + | |
| − | | + | |
| − | === Shared Install ===
| + | |
| − | | + | |
| − | * Lots of different kinds of shared install setups. Spectrum from complete locked down where each user must have exactly the same thing, to a more permissive approach where there is a "profile" of shared stuff, and then each user can add custom things on top
| + | |
| − | * Terminology point: Maya calls the shared stuff the "system profile"
| + | |
| − | * Need to figure out semantics of relationship between profiles - profile hierarchy, inheritance, etc
| + | |
| − | * Reconciling changes to shared profile on startup
| + | |
| − | * Tom raised issue that cascading Equinox profiles is problematic. Profile inheritance doesn't necessarily imply multiple Equinox profiles though
| + | |
| − | * Various parties want to plug in and take over the process of reconciling the profile on startup (Maya, Lotus, etc)
| + | |
| − | * In some shared installs, want to unequivocally upgrade the shared components and throw away the old version. Users are no longer allowed to run on old versions. In other installs, policy may be more lenient and allow the user some control over if/when they upgrade. We should support both.
| + | |
| − | * Discussion around profiles - whether Equinox profiles and Maya profiles are the same. Can a profile be represented as an installable unit?
| + | |
| − | | + | |
| − | = Week of 20070813 =
| + | |
| − | | + | |
| − | == Agenda==
| + | |
| − | | + | |
| − | * Separation of concerns around the artifact repository (https://bugs.eclipse.org/bugs/show_bug.cgi?id=197644).
| + | |
| − | * Shared install:
| + | |
| − | ** How much of the things noted in the discussion (http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg02692.html) are provisioning related vs runtime related (location of preferences, log files, cache, etc.)
| + | |
| − | * Controlling the Engine:
| + | |
| − | ** The engine currently takes an operation to install, or uninstall IUs. Can this separation of installation / uninstallation / update / etc. be kept? How do we reconcile?
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * DJ Houghton
| + | |
| − | * Jeff McAffer
| + | |
| − | * Simon Kaegi
| + | |
| − | * Pascal Rapicault
| + | |
| − | * John Arthorne
| + | |
| − | * Susan McCourt
| + | |
| − | * Dave Stevenson
| + | |
| − | * James Miles
| + | |
| − | * Patrick Dempsey
| + | |
| − | * Stefan Liebig
| + | |
| − | * Ted Habeck
| + | |
| − | * Joe Rusnak
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | We initially attempted an Asterisk conference call, but the line quality was not acceptable. We moved all participants to a private number until we find an acceptable way to do a public call.
| + | |
| − | | + | |
| − | === Artifact repository ===
| + | |
| − | | + | |
| − | We need to be able to perform post-processing steps after download, such as unpack-200, re-assembling compressed deltas. Should the repository be aware of these post-processing steps, or should it be done independently? When mirroring between repositories, some post-processing steps are not necessary (for example unpacking zips/jars
| + | |
| − | | + | |
| − | In our discussion, we distinguish between original bytes (as they are added to the repository from build system), and stored bytes (the actual bytes stored on disk in the repository). When mirroring between repositories it is more efficient to directly mirror the stored bytes, rather than the original bytes.
| + | |
| − | | + | |
| − | We should have different artifact descriptors for each available representation of an artifact (jarred version, delta compressed version, etc). Leave it up to download manager or some other entity on the client to decide which artifact descriptor it wants to load for its current circumstances. The artifact key uniquely identifies the original bytes, whereas the artifact descriptor identifies various flavors of stored bytes.
| + | |
| − | | + | |
| − | Two main methods for artifact repository API: getArtifactBytes(IArtifactKey), returning the "original bytes", and getArtfactDescriptors(IArtifactKey), which returns all the available descriptors corresponding to the given key.
| + | |
| − | | + | |
| − | Tangible next steps are to implement post-processing steps for pack200 and signature verification.
| + | |
| − | | + | |
| − | === Shared Install ===
| + | |
| − | | + | |
| − | Discussion skipped because Andrew Overholt is leading this work and wasn't present
| + | |
| − | | + | |
| − | === Engine discussion ===
| + | |
| − | | + | |
| − | Currently the engine API only allows a single operation to be performed at once. We may want to be able to pass a batch of operations to the engine and have them be performed together (atomically).
| + | |
| − | | + | |
| − | Currently the interesting units are ProvisioningOperand and Phase. An EngineOperation just provides an ordered list of phases. The operands actually provide the interesting behavior (install, uninstall, update).
| + | |
| − | | + | |
| − | Could we specify the engine API instead in terms of states, and an operation is just a request to transition from one state to another. The precise phases required for that state transition are implementation details.
| + | |
| − | | + | |
| − | On a multi-user install, some phases are no-ops because they have already been performed before by another user.
| + | |
| − | | + | |
| − | = Call Info =
| + | |
| − | Weekly call are being held every Monday 11AM EDT.
| + | |
| − | | + | |
| − | Phone:
| + | |
| − | * (+1) 613 287 8000 (Ottawa and international)
| + | |
| − | * 866 362 7064 (toll-free North America)
| + | |
| − | Passcode: 173972
| + | |
| − | | + | |
| − | [[Category:Equinox p2|Meetings]]
| + | |
