On 7/2/07, Dries Buytaert <dries.buytaert@gmail.com> wrote:
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).
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.
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 don't think that reducing the workload by setting up barriers is a good idea. Premature RTBC was not really a problem in my experience. People learn to do the right thing; I can't think of anyone I've had to consistently correct. I did relax the rules as the 5.0 release drew nearer since the point is to get reviews done and not argue about statuses, which discourages developers. I had weeks when I would review a lot of patches and those with few patches, the size of the queues actually stayed relatively consistent. My theory is that contributors keep a consistent mental load of patches in the queue, so the number of patches stays consistent. I believe reducing our queues is not something software will solve. It is a human "problem" that needs a human solution. Automated tests would change the queue size to a smaller constant, if at all. They are are good, but would not alone lead to a very small number of issues. Making reviewing easier will help. I could probably come up with a laundry list of small improvements to project module, but that won't help dww or other project module people. A lot of it is probably in the project.module issue queue. The real winner would be a community change to increase the value of a review. Writing a patch solves your problem. Reviewing help solves someone else's problem. That is why I think there are more patches than reviews. -- Neil Drumm http://delocalizedham.com