while waiting for Dries to officially RTBC the issue for hosting install profiles on d.o [1], i just had an idea for a install profile: the development profile. things it could do: 1) install/configure devel.module 2) setup some standard roles for testing (non-uid-1 admin, content admin, a role that only has "switch users" permission, etc), and configure all perms appropriately. 3) create a small pool of users in each of the roles, all of which are also in the "switch users" role, enable the switch users block from devel.module, etc. [2] 4) also create a bunch of random users with the generate script from devel.module... 5) create a bunch of test content with the generate script. 6) create a bunch of malicious (XSS-seeking) content: node titles, taxonomy terms, anything we can think of that some module might not be escaping properly somewhere. basically, wrap js alert boxes around just about any possible user-input we can find. ;) 7) install as much of the simpletest.module and framework as possible, and otherwise prompt/warn the user about the external library they should download and install. 8) perhaps install some per-node-access module(s) (tac_lite, simpleaccess, etc) and configure some of the auto-generated content to be private. 9) optionally install some other handy modules folks use for testing (i'm a big fan of diff.module and dba.module, but there might be others that would be useful). 10) perhaps install/configure some kind of benchmarking tools (if any exist that would be appropriate). ... this would: a) save a ton of time whenever one of us needs to setup a local test site b) make it *much* easier for newer developers to get a standard test environment up and running c) facilitate being able to reproduce bugs, since everyone could be working from a more standardized test environment most of the time d) lower the barrier to developers running (and therefore writing) simpletests for their code e) help find XSS more quickly, since folks (and automated tests) would be navigating through a site that was trying to XSS-ify itself all over the place. just having the per-node-privacy content auto- generated would help remind folks to test those sorts of edge cases in their code, too. i don't have time to work on this, but i'd be willing to help someone (s) else. or, if anyone thinks this is such a good idea, they want to pay me to work on it instead of my other consulting gigs, that might work, too. ;) if we could stand to wait that long, this might make a nice SoC 2007 project, too. thoughts? -derek [1] http://drupal.org/node/113939 [2] it'd be nice if there was a setting in devel.module to restrict the choices in the switch user block to users that have 'switch users' permission, so that such a test environment would always allow you to quickly switch back and forth across differently perm'ed users, without ever getting "stuck" on a random user that didn't have switch perms...