[development] idea for an install profile (and "distribution"): devel install

[Victor Kane]

Great idea!

1. Should include Earl Miles' new Update
Status<http://drupal.org/project/update_status>module for constant
module status.
2. Should include some software development process plugins on a simple
level. I am thinking of adding some kind of xp (extreme programming) tracker
stuff, which could be as simple as an alternative set of issue status and
types, plus some way of indicating issues by teams.
3. Along these lines, some way of integrating the following concepts with
issues:
  a. User Stories (node type with additional fields (cck) and view)
  b. Test Cases (node type with additional fields (cck) and view)

That way this could come with an "XP Tracker" option built in as another
layer without changing anything "core".

saludos,

Victor Kane
http://awebfactory.com.ar
(upgrade to 5.0 awaiting upgrade data path for projects and project issues
modules  from 4.7: sorry I don't have time to help more :(    )

On 2/28/07, Derek Wright <drupal at dwwright.net> wrote:
>
> 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...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070228/74ec7589/attachment.htm