Meeting to discuss Preview Dump and Reload Plan

Agenda

• Review the proposal - get feedback on general direction
• Identify issues/problems that we haven't thought of
• Identify what areas of the UI still need to be spec'd out
• Tease out actual work items and identify who is doing what

Notes

• Discussion centered around current proposal and other ideas
• John: Posted ideal scenario to the list
  • After installing a new version, we prompt the user to explain that we will upgrade their repository and give them an option to make a backup.
• Bear: Upgrade scenario
  • Profile directory stays the same
  • Profile directory changes
  • Can we open the old repository and dump and
• Andi: 3 instances where an install changes Chandler
  • new Berkeley DB release
  • new repository format
  • new Chandler schema itself
• Dump and reload work the PJE and Morgen have been doing so far covers Chandler schema case only
• How do we get to John's ideal scenario - what are the options
• Backup needs to be done first - can this be automatic? Making the user do a manual back-up isn't great from a user standpoint.
• Done installing...old Chandler launches - does the backup automatically.
• How often will people have to upgrade?
  • This will happen alot
  • Every pluggin
  • new Berkeley DB
  • new repository format
  • new Chandler schema itself
• Sheila: What about dumping the data automatically when you shut down the app? Or at some regular interval.
  • This could run in the background - like sync
  • We have some extra redundancy
  • Checkpointing the data
  • Then when you install a new version we would have the dump there
  • Dump file would probably be where the repository is.
• PJE - Shouldn't Chandler be notifying the user about upgrades and giving them the opportunity to do that
  • Yes, eventually we would like to have this.
  • But we still need to cover the basic case.
• PJE - easiest proposal for us to meet the requirements for Preview
  • Installer installs to a different location
  • Detect a previous version of the repository
  • Gives you the option to load that in
  • You have to have the old version in there
  • Downside: user might uninstall the old version - overwrites old stuff - can't import
  • You can cancel and start with a fresh repository
  • Show some progress bar
  • UI for old Chandler not visible - new version would be pre-splash screen
  • User not aware that we are running the old version
  • Would work in all versions
  • If someone does a tarball install we need to make sure they are warned to not install on top of the old version
• Sheila: If we go with this proposal - do we need to keep any manual options for dump and reload?
• Katie: should keep this as a tool for developers
• Do we will keep the save and restore settings feature? We could keep it as a tool.

• Data - what do we need to dump * All the info we have shared * Do we add in all the account settings, preferences? * Can we save this stuff to an ini like we do now? * Mimi and Sheila will work on full inventory of options.

Tasks and Owners

• See Katie's email thread on Chandler list for the next actions and developer tasks.
• http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007704.html

-- SheilaMooney - 13 Feb 2007