I've heard various statements that a product which sets up a site should use a base profile. I have interpreted this as define all types, all workflow, all toolsets, all skins etc into the profile of that product. For example for plone, one would copy CMFPlone/profiles/default and work from there, filling out the profile to include other 3rd-party products that you want in your custom site.
Is this the right interpretation? What is the argument for a site product to use a base profile? Actually, what is a base profile? Is it not just a particular profile that happens to have a typically replete set of import export steps that cover the import export handlers of GS as it ships? I would have thought a site product profile would include the following: - an ordered set of extension profiles that are applied from an empty initial condition - local overrides for any part of any of these extension profile that you want to change ... i.e. a local extension profile that is applied last (or perhaps a number of local extension profiles slotted into the ordered list of extension profiles) The continual merging of extension profiles from 3rd-party products into a base profile seems to add more work where it is not necessary (just apply the latest and greatest extension profile). This is why I think my interpretation of what a 'base' profile for a site product is wrong. Some of this talk about ordering dependencies and base profiles vs extension profiles in zope-cmf and plone-core-developers (with some bbq sprinklings) is making me wonder about how to really visualise a base profile for a site product. cheers Matt _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests