Development resource list for making and reviewing patches for Drupal core

Resources to help the development of Drupal core mentioned on the development list:

Main patch and review resource (rewritten by Catch):

http://drupal.org/patch/review

Setting up a test environment to review patches (pointed to by Ryan Cross):
http://drupal.org/node/28245

New Testing section of the Getting Involved guide (pointed to by Addison Berry):
http://drupal.org/node/240216

Resources related to patching put together by Ivan Sergio Borgonovo ( http://www.webthatworks.it )

Using CVS to maintain a Drupal website
http://drupal.org/node/93966

R. Keeping Your Local and Remote Sites Synchronized
http://drupal.org/node/120617

Drupal development server configuration
http://www.garfieldtech.com/blog/drupal-dev-server

K. Moving Entire Drupal Site with Databases
http://drupal.org/node/120627

Migrating Database Changes From Development to Live Websites
http://drupal.org/node/199771

Drupal Performance Measurement & Benchmarking
http://drupal.org/node/282862

Drupal with safe mode enabled and open basedir
http://drupal.org/node/82223

More than one Drupal site on one machine
http://drupal.org/node/274

Transforming a default table names installation into a prefix table
names installation
http://drupal.org/node/195758

How-To: Virtual Hosting with Drupal
http://drupal.org/node/80472

For database load testing, recommended by Jamie Holly:
Siege - http://www.joedog.org/JoeDog/Siege

A summary approach for quick patches, from Nat on the development list:

20 minutes is about right to do a proper review, but a lot of patches
don't even apply any more, including RTBC ones.

So if you already have HEAD installed (I pretty much only clean my
database before or after reviewing a patch with an upgrade path or
schema change), you can do this:

// clean your HEAD of old changes.
cvs -q diff | patch -p0 -R

wget http://drupal.org/files/issues/somepatch.patch

patch -p0 < somepatch.patch

1 out of 1 hunks failed etc.

Mark to code needs work with 'needs a re-roll'.

Maybe 45 seconds then, but not too much more than that.

Also simpletest is a much, much easier and more comprehensive way to
avoid regressions that installing devel, generating content and
clicking around. So that stage is reduced to: admin/build/modules
enable simpletest
admin/build/testing run all tests

Although you can go make a cup of tea while the tests run, there's
little effort involved running them. You should obviously test the
actual functionality of the patch on top of this, but that's a bit
less RSI inducing.

Resolution