[development] RTBC - how does it work?

John Wilkins drupal.user at albin.net
Tue Jul 3 18:12:31 UTC 2007


On Jul 3, 2007, at 7:52 AM, Dries Buytaert wrote:
>   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.

The "web of trust" that is described in that article sounds like it  
is already informally implemented by Dries and the other committers.  
For example, Dries would trust a review of a theme-related issue by  
Earl Miles more than he would trust my review of the same issue  
(since I'm new.)  That's perfectly natural.

The issue then becomes: how do patch developers get the attention of  
committers or of the committer's web of trust? The only current  
method is to get it marked RTBC. But then those developers get  
frustrated as their issues languish in an RTBC queue that is the / 
self-described/ last step.

Obviously, RTBC is completely mis-named considering how committers  
are treating that status.

To fix the problem from the persepctive of a non-web-of-trust  
developer and to alleviate the work load of committers reviewing not- 
actaully-RTBC issues, I would propose that:
1.) the current "patch (ready to be committed)" be renamed to "patch  
(ready for final review)". This is ESSENTIAL to, at the very least,  
re-align new developers expectations.
2.) the web of trust be formalized and those developers get a new  
permission to upgrade an issue from "patch (ready for final review)"  
to a new, restricted "patch (ready to be committed)" status.  
(requires project* mod)

Additionally:
3.) patches that are not marked "code needs work" or "to be ported"  
be periodically and automatically checked to make sure they still  
apply without FAILing. (requires infrastructure resources :-( )

Others (like Fernando and Earnie) have proposed a voting system or a  
merit/karma-based system, but, as Dries said, Drupal is not a  
democracy, so those systems would still be out of alignment with how  
core committers are working.

We need a solution that naturally aligns new developers expectations  
with how core development is actually done.

  - John


More information about the development mailing list