[development] RTBC - how does it work?
rob at robshouse.net
Tue Jul 3 16:17:39 UTC 2007
> 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.
More information about the development