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)