[development] RTBC - how does it work?
drupal at dwwright.net
Sun Jul 1 23:47:38 UTC 2007
On Jul 1, 2007, at 7:25 PM, Doug Green wrote:
> I searched the docs and couldn’t find the protocol for this. How
> does a patch get to be RTBC?
This is an excellent question. I'd love to have a section of the
handbook devoted to "Howto use the issue queue", with a page devoted
to each of the possible status values an issue can be in, what they
mean, under what conditions they should change, etc, etc. I wrote a
follow-up in an issue once that could be the start of the "What does
RTBC mean" page, but I don't have time to find that right now.
To briefly answer your question: there's no real answer. ;) RTBC is
relative. Effectively, it means "Ready to be reviewed by core
committers", with the assumption that enough non-committers have
reviewed, tested, audited, etc, to catch the obvious problems.
Different people set an issue to RTBC with various levels of effort.
Some will RTBC just on a visual inspection of a patch. Others will
only do so if they've reviewed, audited, applied, tested, etc, etc.
Basically, you build up a reputation for how much your RTBC "counts"
based on how thorough your reviews are when you mark issues that
way. And, even if you've built up quite a reputation for careful
RTBC'ing, that doesn't mean Dries actually agrees with you, so the
swift axe of "needs work" will come down, anyway. ;)
That said, D6 has suffered from an insanely large RTBC queue for way
too long. 40-60 RTBC'ed patches in the queue for weeks on end is a
sign that our process is breaking down. Obviously, Dries's
(announced in advance) absence in the crucial week before the freeze
didn't help, and we can't make demands on the core committers to
"work faster" if lots of good patches are coming in. But, it really
is tragic how much good code was in fact ready to commit, and the
core committers just ran out of time to get to them all. The
Deletion API debacle certainly consumed a lot of precious time, too.
There is much frustration floating around the community right now,
and I don't have any answers for that. On the other hand, many of
the issues that were marked "RTBC" probably weren't -- careful review
would have found problems and a better patch could have been posted.
Basically, if you're working on an issue, and someone RTBCs it, don't
think that's the end of the story. Did they do a thorough job
providing evidence for why it was ready? Was it just "I love how
this works, RTBC!"? Put yourself in Dries's shoes for a second, and
consider if you'd be able to trust the reviewer(s) and commit the
code or not. If not, solicit more reviews to give it more weight. ;)
More information about the development