Proposal: drupal.org testsite install profile

this is an idea i've been thinking about. posting it here so other folks can add to it, provide feedback, etc.

Summary

we could really use an install profile that setup a test site similarly to how drupal.org is configured (especially the project* modules and CVS integration). obviously, it wouldn't have the bluebeach theme, but otherwise, it would look fairly similar to d.o in terms of structure, content, permissions, etc.

this would greatly help people who wanted to reproduce bugs and test patches for the project* family of modules, which is something we desperately need more of. it also might be a popular profile as a starting point for people looking to setup software-collaboration sites (though ideally we'd have a separate "software development site" profile eventually).

here's what i envision (but please edit this to expand or modify it):

• enables and configures all the project* modules and the CVS repo stuff
• sets up the d.o project taxonomy stuff (project types, module categories, etc)
• enables and configures the devel.module
• configures the d.o roles and permissions
• generates a bunch of random users
• generates a few targetted users for each of the main roles on d.o, with documented usernames and initial passwords
• generates a skeleton set of project nodes (core, some of the common contribs, cross-section of different project types (modules, themes, translations, etc))
• generates a bunch of random releases
• generates a bunch of random issues
• (optionally) generates some random forums and comments
• ...

so, you download all the right versions of things, install this profile, and you're ready to start testing patches for the d.o infrastructure.

in his "State of Drupal" talk, Dries was making a plea for more people to help with making our home on d.o more like a palace. this should significantly facilitate getting more "builders" involved in the construction. ;)

Details

specific modules

see http://drupal.org/node/27367 to start with. ;) otherwise, contribs i'm specifically interested in, are:
* cvslog
* project (including project_release)
* project_issue
* code filter

taxonomy

The project taxonomy stuff is a little weird. you get the basic idea: there's a "project" vocabulary, which is hierarchical. top level terms are "Module", "Theme", "Installation profile", etc, etc. At this point, only Module has sub-terms, which are the module categories (see http://drupal.org/project/Modules for a list of them). Once http://drupal.org/node/105986 is done, and contrib translations are in their own projects, we'll have sub-terms for each language under the "Translations" term, but that's getting ahead of myself. ;)

There's also the project release vocabulary -- "Drupal Core compatibility" (for the "5.x", "4.7.x", etc terms on release nodes, which is also used in a bunch of the download pages, etc).

I see 2 possible solutions for this:

1. you just manually re-create a subset of this structure (not every single module category, etc)
2. we actually export the relevent records from the {term_*} tables directly (and regularly) from d.o. not sure this idea will fly, but perhaps we could have a cron job that just does a selective mysqldump and sticks the .mysql file somewhere folks can just download. ;) i'm *only* talking about the structure of the project (and project release) vocabularies, nothing more.

cvs repository

ideally, the install profile would include a tarball of a pre-configured cvs repository that had the right basic directory structure, and some files for the project nodes that would get created with the profile. all the contributions/modules/cvslog/xcvs* stuff would be configured in the CVSROOT of this repo, and would be customized during install to point to the right drupal database. there's a pretty thorough README.txt in there now. we'd probably want to create 2 repos, in fact -- the contrib and core ones.
then, of course, the drupal site would be configured to know about each repo (via [site]/admin/project/cvs-repositories).

specific nodes

i don't think it's feasable or desireable to actually replicate all of the project, issue, and follow-up content from d.o. i was thinking we'djust creating a small handful (~10) different projects that are representative of the structure on d.o. these would be the same small handful of directories in the stub CVS repository. they'd have some specific CVS tags and branches, too, and the corresponding release nodes. once that's in place, i'd say we just randomly generate a bunch of issues and comments automatically.

roles and permissions

i'm not sure how much of this i can share, nor how much of it is really necessary for the needs of this profile. basically, we should just configure the anonymous and authenticated users with the appropriate perms, and then make an uber-site-admin role with all perms enabled. the whole "document maintainer" vs. "site maintainer" vs. "site admin" stuff probably isn't essential -- though it might be nice to tackle in a future version once the other parts are working smoothly.

other settings

i'm not sure what's the best way to deal with this: if i should (can?) just provide a dump of the relevent entries in the {variables} table, like i'm proposing for the {term_*} stuff. i'll try to get some of the more senior powers that be to comment on this part, too.

Related Links

Instructions on setting up and configuring cvs/project* are here. There is also a correspnding demo site which anyone can create an account at and play around with the stuff we're working on.