Quoting Dries Buytaert <dries.buytaert@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