[development] Perm for setting RTBC - Re: RTBC - how does it work?

[Earnie Boyd]

Quoting Dries Buytaert <dries.buytaert at gmail.com>:

>
> On 02 Jul 2007, at 19:07, Augustin (Beginner) wrote:
>> It is obvious that you three cannot cope with the work load:
>> http://drupal.org/project/issues?page=3&projects=3060&states=14
>
> Where is the rule that says the queues must be empty?  During the  
> Drupal 5 development cycle, we also had 3-4 pages worth of patches  
> that are RTBC.  It's not uncommon, and I don't think it is  
> problematic (but I agree that it can be frustrating).
>

The rule is in the wording of "Ready To Be Committed".  Based on what 
I've read RTBC really means "Ready For Committer Review".  As more and 
more developers are drawn to Drupal; Drupal operational style must be 
clearly stated.  Stating "Ready To Be Committed" states to others that 
the patch is waiting on someones precious limited time to commit the 
changes without further consideration.  It becomes problematic when the 
resources move on because the frustration of dealing with Drupal 
operational style (or understanding it) is more than the developer has 
time to deal with.  I suggest that in order to help make the 
operational style more understandable that the wording Ready To Be 
Committed be changed to Ready For Committer Review.

> All in all, I don't think your assessment is accurate.  As long we're 
>  making good progress on one or more fronts, I think we're in good  
> shape.  Committing more patches makes it harder to keep on top of  
> things, make it harder to maintain the quality of the code,  
> encourages politics, etc.
>

This is understandable but not if the status of the patch is "Ready To 
Be Committed".  At the RTBC point the developer is understanding that 
he is waiting on someone to apply the patch to his working copy and cvs 
commit it.  From the developer POV not committing every RTBC is harder 
because sometimes the development of one patch is related to the commit 
of another.

> Either way, tt's *not* my goal to commit all patches.  It's my goal  
> to create a great release.  This means I prioritize patches.  We have 
>  a lot of great new features in Drupal 6 and at the end of the day,  
> that's what count IMO.
>

I am sure that every developer who has created a patch for Drupal core 
has the same goal.  New features vs code improvement are two very 
distinct issues.  Perhaps a cycle of coding efforts where focus is on 
code improvements instead of new features should be considered.  
Perhaps cycling the patch queues so that patches related to new 
features are focused beginning January and July while the patches 
related to code improvements are focused beginning April and October.  
Or maybe a four month cycle should be considered where the fourth month 
of the cycle is always the code freeze.  At any rate, this thread is a 
cry for change in operation.  Rewording RTBC to RFCR is the easiest to 
consider and one I strongly suggest be taken.

Earnie