[development] RTBC - how does it work?

[Robert Douglass]

AjK wrote:
> One question I have to ask though. I can full well
> understand the process whereby core committers review
> before commit things like "feature requests" (aka The
> Deletion API) and impose their own feelings on the
> issue in general (+ or -) but if an RTBC is marked as
> a "bug" and has, say two or three reviews from
> "trusted reviewers" can't these just be committed "as
> is" without core eyes on the patch? Afterall, you can
> roll back if it's a problem later. (Or maybe you just
> do this already and it's just more of a bottleneck
> than I had thought?)
>
> --Andy (AjK)
>
>   

I don't want a Drupal that has code in it that a core committer hasn't 
personally reviewed. The discussion up to now has focused greatly on how 
to present code to the core committers that they hopefully only have to 
review once, and then commit it. To recap, this would mean:

- more rigorous effort on patch submitters to discuss and vet the *idea* 
and *approach* of their patch before submitting code.
- more rigorous effort on patch reviewers to think as if they were Dries 
and provide quality reviews.
- possible technical aids like automated patch testing to find out 
whether the patch applies, whether it meets code style requirements, and 
whether it causes any catchable bugs (as per test suites)

If we do those steps, then the core committers job would involve a lot 
more cvs commit -m "good job" and a lot less status->code needs work.