Currently, new Plone sites are created via a "PortalGenerator" object, which contains a bunch of Python code which performs all of the steps necessary to generate a new Plone site in your Zope instance.  This works, but it's not really ideal; initial site setup is really more about configuration than code.  With this setup, if you want to change the way a site is initialized, you have to first let the regular site install itself, then, using what is mostly boilerplate code, you have to procedurally make modifications to the site that is generated.  All add-on products basically do this; they have an install method that runs code performing all the necessary site configuration that the product requires to function.

At the CMF level, however, a new way of configuring portals was developed, in a product called CMFSetup.  CMFSetup let you specify site configuration options via XML; various XML files would specify the tools, types, workflows, properties, and initial content that should exist in a site.  A collection of these XML files would be called a site profile.  Additionally, the idea of extension profiles was introduced.  Site profiles defined the fundamental site configuration, while extension profiles could define optional additional settings that the site maintainer could apply at any time.

Even better than this, however, was the fact that CMFSetup could also allow for site exporting.  Thus it was possible to manually configure a site using the ZMI, and then use the setup tool to generate the XML files of the site profile when you were done.  Snapshots were also possible, so site managers could capture the site's configuration at any moment, comparing it with earlier or later configuration snapshots as desired.

But what's all this past-tense, then?  Has CMFSetup gone away?  Yes, sort of.  CMFSetup was so useful, that folks outside of the CMF world wanted to be able to use it.  Hence GenericSetup was born, which provides all of the same functionality to plain ol' Zope 2.  CMFSetup is still around in it's vestigial stages, but the stuff that used to be in CMFSetup is rapidly being rolled into CMF proper, and soon CMFSetup will be no more.

Several weeks ago, while in Fredericksburg, VA, at a sprint funded by the Goldegg initiative, I started working on getting Plone to work with GenericSetup.  I've been working on it fairly steadily ever since then, with a great deal of help from Brent Hendricks (thanks, Brent!).  At first we were working against the CMF trunk, which is targeted to become CMF 2.0.  It was realized during this time that the product breakage that CMF 2.0 would cause would be too much for Plone to assume in an upcoming release, however, so instead the CMF 2.0-style GenericSetup configuration code was back-ported to a newly cut CMF-1.6 branch.  CMF-1.6 is intended to stay very similar to the currently supported CMF-1.5, with portal configuration being the only difference.

This effort is coming very well; we now have a solidly working CMF-1.6, with all unit tests passing, and there is a branch of Plone that mostly works with CMF-1.6.  Things are not completely solid yet, but most unit tests are passing, you can add a site TTW, and within another week or so we should have the remaining problems sorted out.  There is a PLIP that formally proposes this to be included in the next major version of Plone, which the framework team will be considering over the next weeks.

Eventually, the goal is that  GenericSetup-based infrastructure will become familiar to anyone who does Plone product development.  The portal_quickinstaller would become just a wrapper object that provides a nice interface around the management of extension profiles.  Plone's migration engine would no longer try to modify pickled objects in place, but instead would export the content to XML and then reimport it.  (Kapil's XMLIO proposal will likely be a key component here.)  Anyone interested in learning more about how this works should take a look at the portal creation code in CMF-1.6 and/or the PLIP 113 review bundle.