[development] RTBC - how does it work?

[Derek Wright]

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. ;)

Good luck,
-Derek (dww)