Since December 1st 2009 we've had distribution packaging working on drupal.org - yay!
1. External dependencies
Modules can require a user to download external libraries like jQuery UI, CK Editor or Simple Pie and ask her to place them into very specific places in a site's directory. This is a small and acceptable hurdle for modules, but install profiles are geared towards a different audience. A given Drupal application can potentially contain various external libraries in different places in Drupal's directory, and placing them correctly and troubleshooting any misplacements can be difficult for the Drupal novice. Moreover, linking a specific library version hard to an install profile will allow for making sure that a given installation, if not modified, contains a given library version, which facilitates debugging.
There is consensus that rolling offsite libraries into distributions is a good idea, however there was a heated debate on whether it would be legally advisable to do so. The conclusion was that a whitelist solution would be acceptable. A whitelist would allow specific external libraries to be added into a distribution. External libraries would not be committed directly to the distribution's code base, but tied in via a drush make manifest.
There are 3 classes of things we need to tackle to call this resolved:
That issue is about actually building the whitelist plumbing on d.o itself.
Ensure that the existing packaging whitelist nodes have all the fields we need to do their job. Display the whitelist in human-readable form to distribution maintainers (and potential maintainers) so they know what 3rd-party code is currently allowed. Display the whitelist in machine-readable form (e.g. JSON) so that drush_make can enforce the whitelist during packaging. Create a feature including the whitelist content type, fields, views (html, json, rss) and related code for deployment and ongoing maintenance.
Also, once we know what external code is packaged with each distribution release, we can provide views of projects + releases with filters for 3rd-party code so that the Security Team can find all the affected projects when upstream security problems are reported and we need to do security update releases and publish SAs. (TODO: turn this into an issue).
Building a Drupal site almost always requires patching a module that is maintained by somebody other than the site builder. This is no different when building an install profile. Moreover it's not possible to wait while patches are committed upstream before releasing an install profile and packaging its dependencies. Even very obvious fixes to a module can take too long to be committed to their respective module.
drush make (the drush plugin powering profile packaging on d. o.) supports adding patches to modules in the package:
projects[ctools][version] = "1.2"
projects[ctools][patch] = "http://drupal.org/files/issues/ctools_plugin_static_cache.patch"
This features effectively allows for decoupling upstream (core or contrib) fixes from downstream (profile) releases. This is important as it frees profiles from waiting on upstream fixes and it encourages contribution to dependencies.
3. Themes and modules in installation profiles
Most Drupal sites have one or more custom modules containing "glue code" specific to the site's use case. The situation is very similar with themes. This is again, no different with install profiles. Currently, there is no other way of adding a custom module or a custom theme to a packaged profile than committing it to contributions/modules (or /themes) and thus including it like any other module or theme. This practice pollutes an already constrained namespace which should be avoided.
Allow modules and themes to be committed to installation profiles, discourage users to commit contribution modules or themes directly.
4. Development snapshot releases (-dev) in distributions
This item covers changes to allow distributions to package development snapshot releases of the modules and themes they include. This is necessary when upstream project maintainers do not ship official releases that include necessary bug fixes or new features when the distribution is ready for a new release. Currently, -dev releases are prevented from being included in profiles, but the work as outlined here would lift this restriction going forward.
However, packaging from a development snapshot produces instability for the distribution maintainer, since it becomes harder to know exactly what upstream code was included in a given release of the distribution. This can be resolved by the following:
Workflow and tools for distribution maintainers
We will need to communicate these significant changes to the packaging infrastructure and make sure that profile maintainers are aware of them:
+ Write up an explanatory announcement in the style of "Fully packaged Drupal distributions now deployed on drupal.org" http://drupal.org/node/647374
The Drupal Security Team should have a discussion about our process for SAs when 3rd party code vulnerabilities are published.