[ Edit ]
To make a long story short, it turns out that robroy was already well ahead of me in figuring out why the old documentation wasn't helping people and will update the documentation next week. Serious props to his chops for the effort.
If you're interested in how this is shaping up, take a look here.
[ / :) ]
I noticed webchick had pulled the old documentation for writing installation profiles a couple of days ago, and after kiting her a brief email, feel like I know what's going on with Drupal, for once, or at least the docs. Short version being that the old ones were as dated as they appeared, and new ones will require a little research to complete, so I will be taking a stab at this over the next couple of days.
While what I am planning is a standard-issue how-to and maybe some side notes (there's a macromaker that didn't make it into core but is now available with the devel module, for example), I figured besides a heads-up, an RFC vis-a-vis the vision thing might be of interest. My plan is to dogfood my way through a generic profile to familiarize myself with the stuff in install.inc and so on, but so far, I believe there's some latitude to do more than just a single form with installation options and a submit button.
As I kind of intimated with my earlier posts, my two ideas have been 1) to encourage installation profile developers to become responsible maintainers and promote the idea that quick and dirty installers hacked to do whatever are great so long as new users don't get hold of them and try to upgrade production sites and so on. 2) provide some suggestions and examples of creating interactive installations that allow the user to choose different configuration options from within a single profile using forms (I think this is doable, still) and more importantly, simulate the new-user handholding process with the script in an attempt to educate them a little in the process.
Naturally, I've already downloaded a copy of site_tour to play with for ideas.
But with the understanding that I'd happily produce a series of terse, ordered lists containing nothing but PHP markup and engineering speak to prevent the proliferation of various "Droomla Nuke: Web 2.0 Gold Pro Deluxe" distros and thus will make every effort to err this side of caution, heck.
That's what I'd do if I could wave a wand and come up with anything I wanted, or as much as I've thought of so far. Maybe an installer that could bring you an irish coffee in the process or walk your dog.
Otherwise, here; try out the magic wand a second and let everybody know what kind of installer you'd come up with in a perfect world. Ideas and excitement are certainly appropriate with the upcoming release; having Drupal subverted by spammers and 13 year olds with hosting companies can wait a bit.
Comments
Wrong documentation is far worse than no documentation.
I unpublished it after about the 6th time in a week of someone asking in IRC why hook_configure wasn't working, or why thing X they were trying to do wouldn't work, etc. and citing that document as the source of confusion. It doesn't make sense to keep pages like this around. So I would hardly call this 'evil' :P I wrote the page initially, fer crying out loud. :P It's just that the patch it was based on and what went into core and devel module since are two very, very different things so a lot (most?) of the stuff in there no longer applies.
You might want to post to the Documentation project issue queue about your plans to update this page; others might be interested in helping you out!
Oh, no...
I didn't think that was evil at all.
On the other hand, I've also connived my way into the ability to influence every new Drupal user's first impression of the software, if that isn't Machiavellian, what is? :D
About this documentation
Is it more of step-by-step technical guide or does it veer into other areas such as putting together a team, how to responsibly manage/maintain a profile, and other best practices? I'm interested in contributing to this type of distribution (I've already laid down a lot of the groundwork), but am unsure how to move things forward...
Gus Austin
(And then I was BEHIND)
Hopefully, by now, everyone's picked up on the fact that Robroy's already updated the documentation for creating installation profiles. If not, sorry I didn't post this sooner but I've been sidetracked with a bunch of other stuff.
And to answer your question, it's very specific to writing the actual code, and what is needed to make the installer script actually work with a specific profile.
Otherwise, my best advice would be 1) Test the waters and see who else wants to put together something similar 2) Find out who wants to do what if other people want in on it, or, if it's just you (or you and them, regardless) 3) Do the sucker. Dries wrote this about being a responsible maintainer, specifically, but there's only so much planning and diagramming and so on accomplish and they'll never equal actually DOING the thing.
More than anything, I'd be aware that 1) There's no provision in CVS for individual distribution projects at the moment -- and the dev mailing list will likely be a whole lot more receptive to a site that can demo a planned distribution profile in terms of figuring out how that should be implemented. Beyond that? It's all documentation and getting people to put issues in the issue cue and support requests in the forums where they can be identified as belonging to your distribution. But that's a ways into the future...
Definitely some interest...
What zirafa posted about here, was pretty much identical to what brought me over to Drupal in the first place (although I was calling them 'template based or plug 'n play solutions'). Think there are a lot of others who are interested in this type of thing.
Even though a finished distribution could have a lot of business value, it's a bit more of trick to get the 'right' people to make a commitment. People's time does not come cheap.
As far as using Drupal groups as a platform for collaboration - Is it suggested that there be a separate group for each type of distribution (like DupalEd)? What about a site whose main differentiator is the content that's put on top. For instance a newspaper/magazine, social network, or blogging style install profile could be part of many different 'topic/niche based' distributions (arts/music, education, business, etc.). Would it make sense to create a working group for each of these types of generic profiles (blogging install profile group; newspaper/magazine install profile group; social network install profile group), or collaborate within a pre-existing group? I'm sure there's a better way of asking the question...
Gus
What am I trying to do with Drupal?
Gus Austin
One more thought...
Something that just occurred to me as important: if one's going to put together a distribution profile, it's going to be necessary to take into account creating a new profile with the NEXT release of Drupal that will A) Allow the site to be upgraded to the current Drupal version and attendant contributed modules and B) take into consideration any quirks that might be introduced by new versions of contributed modules being released and installed in an existing site.
Adds a new dimension to the planning process, no? ;)