[development] Perm for setting RTBC - Re: RTBC - how does it work?
earnie at users.sourceforge.net
Tue Jul 3 13:24:56 UTC 2007
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:
> 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
> 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.
More information about the development