Package Management

definitely.. like an iTunes music store for the web.

Front end builder/wizard to create your appliance from existing Drupal sites.

That's not my goal for the Web UI. I intend to use as much of the existing interfaces for exporting existing code as possible. The Web UI I'm talking about will store the exported data and make it easy for people to mash up online without a local Drupal installation.

Once you have an appliance created your appliance would look like:
-- Drupal Appliance package
---- Drupal core
------ Patterns install profile (improved to allow interactive patterns - wizards)
-------- Patterns (Features)
---------- Modules

Some of these changes are just in terminology:
-- Virtual appliance (package in a lamp virtual machine)
---- Software appliance (package and base distribution in a tar)
------ Base Distribution / Personalization Wizard
--------- Packages (Patterns just for menus, blocks, roles/perm, but I'm trying to get away from adding another dependency to the system)
----------- Components (contributed modules, a set of shared configurations, and/or external plugin/extension integration)

Integration with Drupal.org infrastructure and Project module. To have it create a tarball of Drupal, the Patterns and the Modules.

Definitely. Components, packages, entire distributions, and even entire virtual machines will all be available.

Ideally this would be made to also work for smaller feature packages rather than the whole "application" so they can be shared and mashed up.

Exactly! These are, what I'm calling, components; or more specifically, they're shared components. Mashing is preceded by sharing.

I would be happy to discuss further and help or mentor for this if needed.

Email'd you!

One of the main items of work that would be a fantastic help would be to upgrade the packaging scripts on Drupal.org to make downloadable install profiles with required modules aka dependencies.

Great, that's on the top of my list for my builder script.

This alone is a pretty big job, from figuring out where to store dependency information (ship a .info with profiles?), how to refer to a version of a module, and so on.

Any new "feature" would have its dependencies listed in the underlying packages or individual meta-package, not the Base Distribution. I intend to avoid using the installation profile for anything more than establishing a foundation for both site builders and feature developers.

The Web UI should allow users to package (verb) specific releases of a module rather than just the module itself, and this would be reflected in the package's info file. Perhaps a backport of Allow specifying version information as part of module dependencies would be necessary for 6.x.

Adrian has a long post on package management and dependency checking that seems relevant.

Aegir is bigger bite than I can chew. My goal, in this respect, is to give package developers a far simpler environment from which to assemble the changes they have made, to the Base Distribution or another derived starting point, into a package.

"You'll be able to roll out new features incredibly easily, and seeing that you can extract features with Drush, we can automate that too." -adrian
I'm not sure what adrian means by extracting features. I think he's referring to granularity with, what I termed, components and configurations. In the end, I believe, features and my solution both seek to provide a module whose parts are also manageable apart from the module as a whole.

The rest of what you're talking about is, essentially, profile / package wizards

Wizardry, yes. Multiple install profiles, no. Most importantly here, I want to emphasize that I'm not developing a local wizard for package management. My plan is to make something suitable for inclusion on drupal.org or a LAN, like an open source version of iTunes Music Store/iTunes network sharing, for Drupal packages and distributions. The local feature management UI isn't something I'm concerned with. Features and buzzr both have potential in regard to the site builder UI. This is equally true for UX improvements to admin/build/modules.

New idea: the modules page could be replaced with features, and a new .feature file could list its dependencies. (this is a very new thought) perhaps features could replace my current ideas on meta-packages.

(however it's implemented - patterns / context / spaces / etc. etc.). I'd much rather see some of this starting to get worked on moving to core

As a general rule of thumb here, we shouldn't count our chickens before they've hatched. Patterns / context / spaces / features are all in alpha, and a leap forward as big as this will need a significant amount of testing / adoption, so that we don't realize later: our choice doesn't share the same fundamental design as the rest of the code, ie. has unnecessary dependencies or is insufficient for broad adoption/development.

To help establish the history/trends of packaging and hopefully even what I mean by "fundamental design", I'm working on a Packaging / Distribution Helper comparison table.

In terms of core's needed improvements, I have plans for this in my proposal. Imo, the only lacking features, atm, are exportable blocks, menus, and roles/perms. Everything else is already easily exportable. And, modules already provide a method to install/update everything that I can think of.

Packaging can and should continue before this point is reached, because in the interim, I can leverage Patterns, the best minimalist, work-around solution. It would allow packages to avoid cli-scripting, like DBscripts or drush, and only requires one additional dependency. Later, the patterns dependency can either be moved into core or removed if we choose the core improvements instead.

... but the implementations all seem pretty varied and no one has had the time to really work on a core approach,

"You can never plan the future by the past." --Edmund Burke

which would make it hard for a GSOC project.

This project is a long time coming for me. Trust me, I will complete it.