GenericSetup already offers a number of advantages over previous mechanisms for managing site configuration. It promises to solve even more problems, however. This section will talk about some of these possibilities, and what still needs to happen before these possibilities can become a reality.
The first area that could be improved with the use of GenericSetup is the Plone migration infrastructure. Currently, migrations are handled by tracking the installed Plone version number. If the filesystem version of Plone is higher than the version stored in the ZODB, then the migration tool can be used to run all required migration steps, which are defined in Python as a set of operations to perform.
That's right, it's not much different than the earlier product installation or site creation mechanisms. In fact, a number of migration steps, such as changes to action or workflow definitions, could be achieved via GenericSetup-land just by the application of a new profile.
It is evident that this use case has already been thought about; in the import_steps.xml file for most profiles you will see a 'version' attribute on all of <import-step> tags. This is meant to be used like a serial number on a BIND zone file, for those of you familiar w/ BIND. For those of you who aren't, the idea is that you'd set the version to be related to the date, something like 'version="YYYYMMDD-01"' would work. Whenever you make changes to the configuration, then, you'd update the version of the import step. Then the setup tool would be able to tell you which import steps were out of date, making it easy to select them and apply the new config to your site. The interface that makes use of this version attribute is not yet in place, however.
Okay, that would cover a number of migration tasks, but there are other tasks that cannot be represented simply by a change in the configuration. Florent Guillaume gave the example of merging two content types into a single one; you could represent the new set of content types easily enough, but there's no way to represent the step where some of the existing content is converted to the other type. CPS has already tackled this problem within their own usage of GenericSetup; they've introduced a new ZCML directive that looks like this:
title="Replace CMF URL tool with a CPS-specific one"
This registers an upgrade step with the system. As is clear, it specifies the source and destination versions, and the callable handler that actually performs the operation. It also registers a checker method, which will ascertain whether or not the upgrade step actually needs to happen.
As we have already seen, GenericSetup can be used as an alternative to CMFQuickInstaller as a way to install your products into a Plone site. While GenericSetup is a better approach to product config management, it is not yet ready to completely replace the trusty portal_quickinstaller completely. First, the GenericSetup interface is a bit unwieldy compared to QI. Second, there is not yet any support in GenericSetup for uninstalling profiles. For site configuration management this isn't such a show-stopper, but it's considered a core feature for add-on product management.
Another advantage to using GenericSetup for product installation will be that all products will then be able to use whatever migration features GenericSetup makes available. As described above, Plone has its own migration system. Products often require migration as well, however; currently, each product needs to implement its own migration engine in order to get this support. When all products are managed as GenericSetup profiles, then GenericSetup will become the shared migration engine.
So when is all this glorious work gonna get done? Well, this is open source, so the only correct answer is "When the people who have the skills to do so get around to it." Do you have the skills to where you could contribute to these efforts? Do you have some time to help? If so, then what are you waiting for? Download the latest GenericSetup code from the Zope svn repository and get going!