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.