--- Dries Buytaert <dries.buytaert@gmail.com> wrote:
On a related note:
http://www.computerworlduk.com/technology/hardware/processors/news- analysis/index.cfm?articleid=604
Makes for an interesting read, and shows what might be ahead of us.
On another related note, there was discussion sometime back about the amount of "good support for Drupal" was available. The crux of that argument went something like this, "as more and more people download/install/use Drupal the more support that's required". But the vast majority of support comes from volenteers in the forums (and a few in #drupal-support). For those that missed it here's an interesting link: http://buytaert.net/scaling-community-support Now, map the fact that support requests is similar to patch contributors and support givers are core committers and I see one thing. It may not be an exponetial growth is patch contribution, although it is increasing, what is static are the number of core committers. If core committers would rather be writing their own code then reading others then maybe it's time to find "trusted committers" who, err, can't write code ;) They would then have to rely on the reviewers and gain the trust of reviewers. </2p> Given that that's unlikely people who submit patches will just have to realise they are in a queue (that's why it's called the "patch issue queue") and at the end of the queue there's a bottleneck. 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)