Help me improve my continuous deployment workflow

I've been developing a workflow for practicing a mostly automated continuous deployment cycle for a PHP project. I'd like some feedback on possible process or technical bottlenecks in this workflow, suggestions for improvement, and ideas for how to better automate and increase the ease-of-use for my team.

Core components:

• Hudson CI server
• Git and GitHub
• PHPUnit unit tests
• Selenium RC
• Sauce OnDemand for automated, cross-browser, cloud testing with Selenium RC
• Puppet for automating test server deployments
• Gerrit for Git code review
• Gerrit Trigger for Hudson

EDIT: I've changed the workflow graphic to take ircmaxwell's contributions into account by: removing PHPUnit's extension for Selenium RC and running those tests only as part of the QC stage; adding a QC stage; moving UI testing after code review but before merges; moving merges after the QC stage; moving deployment after the merge.

This workflow graphic describes the process. My questions / thoughts / concerns follow.

My concerns / thoughts / questions:

• Overall difficulty using this system.

• Time involvement.

• Difficulty employing Gerrit.

• Difficulty employing Puppet.

• We'll be deploying on Amazon EC2 instances later. If we're going about setting up Debian packages with Puppet and deploying to Linode slices now, is there a potential for a working deployment on Linode to break on EC2? Should we instead be doing our builds and deployments on EC2 from the get-go?

• Another question re: EC2 and Puppet. We're also considering using Scalr as a solution. Would it make as much sense to avoid the overhead of Puppet for this alone and invest in Scalr instead? I have a secondary (ha!) concern here about cost; the Selenium tests shouldn't be running that often that EC2 build instances will be running 24/7, but for something like a five-minute build, paying for an hour of EC2 usage seems a bit much.

• Possible process bottlenecks on merges.

• Could "A" be moved?

Credits: Portions of this workflow are inspired by Digg's awesome post on continuous deployment. The workflow graphic above is inspired by the Android OS Project.