Workspace for the folks working on GenericSetup at the BBQ Sprint.

Itching, burning sensations

(or current GS issues we'd like to improve)

• You shouldn't have to make extension profile the "active" profile in order to apply it... horrible UI, doesn't fit how things really work
  
• Baseline vs. Extension profiles (UI is unclear re: the distinction)

• It's safe for extension profiles to add new objects, skins, profile steps, etc.  It's NOT safe (i.e. safely revertable) for an extension profile to change something that was originally set by the base profile.  Example: It's fine to add a new workflow in an extension profile, but it's dangerous to reassign the worflow associations that were specified in the base.  Makes sense to make a clear differentiation btn the "safe" stuff and the "dangerous" stuff.  Also possibly the dangerous stuff should be handled by migration steps.
  

• Noisy diffs (TAL-generated XML isn't cleanly text diff-able)

• blocks delta profiles

• Profile switching
• GS could be a good migration engine

• CPS already has a pretty good starting point for GS as a migration engine
• There's "version" info supported for import steps, but it's not used currently; UI should reflect any steps that have newer versions on disk than was most recently imported
  

• Persistent state of profile steps in the portal_setup tool
• No current support for profile dependencies
• Content import/export should probably be separated out from the configuration policy
• Would be nice to have FTI objects that are like FSDirectoryViews, not editable in the ZMI, customizable in a similar manner to skins objects
• (Plone only) Snapshots complete, but for some reason the browser doesn't return, just keeps spinning
  

Things a profile needs to tell about itself at registration time

1. location of the profile on the filesystem
2. base or extension?
3. interface for which it's registered
4. (not yet implemented) profile dependencies
5. (not yet implemented) some sort of revision specification for the profile