[development] RTBC - how does it work?

[AjK]

--- Dries Buytaert <dries.buytaert at 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)