Another good way to help out, is for the patchers themselves to check their patches. I always test my patches on as many systems I can. Usually on my own localhost (The free Xitami, MySQL express, PHP 4) and on a linux box (sometimes my own, sometimes a donated one). This way, I can confidently say that my patch was tested and worked on these various systems. Robin On 7/29/05, David Barnes <eglish@gmail.com> wrote:
After reading the discussion thus far, it seems the bottleneck for development is the testing/reviewing/benchmarking of patches, not the amount of core contributers. So how about we create handbook page(s) describing standards or guidelines the core developers want to see in the commenting of the patches. This would hopefully help eliminate the '+1' comments and possibly prodive some useful documentation if a committed patch winds up causing problems. Also if we have certain conventions, we could have patch testing phases. For example, 'patch phase 1' would be an initial commit of a patch. 'Patch phase 2' would someone reviewing the patch to make sure its fits with drupal/PHP conventions, doesn't break drupal, and is still relevant to the version of Drupal the patch is for. 'Patch phase 3' would be comments on the testing of the patch, like how well it tackles the actual problem, how well it functions with/within the current system, and how well it is written (i.e. not a hack job). And 'patch phase 4' would be some simple benchmarking.
If its clearly documented on how it should be done and presented, that would allow more people to help with patches, and letting the core contributters focus on the acutal numbers, instead having to make the numbers themselves.
On 7/29/05, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 29 Jul 2005, at 11:17, Gerhard Killesreiter wrote:
I said this before and I'll say it again: the problem is not the committing but the reviewing.
No, one affects the other. In the past weeks I haven't reviewed any patches because I knew that both you and Steven were too busy to commit them and that by the time you'd have the time, I'd need to look at the stuff again. This is discouraging. I am pretty sure others are thinking the same.
If a patch is tested, reviewed and benchmarked it takes me one minute to process it. In such a scenario, I can commit up to 60 patches in an hour, or empty the patch queue in an evening. This won't happen as I often spend 30 minutes testing, reviewing and benchmarking a particular patch. Testing big patches like the node revision patch easily takes me 1 hour. The node revision patch could have been committed weeks ago if only enough people cared about it. Adding core committers doesn't help. Adding more status flags to the project issues makes a patch's status more explicit (good) but doesn't change the fact that we'll need to spend a couple hours testing the node revision patch.
I tend to ignore +1's unless I sense that the commenter put time and effort in evaluating a patch.
See above for my reasons not to invest both. Contrary to what Bèr believes, I have no time to waste either.
I'm perfectly happy with you -- or other people -- not investing time/ energy in reviewing patches. If you believe testing, reviewing and benchmarking patches is a waste of your time, then I guess I "waste" at least 2 hours of my time a day -- especially because many reviews go unanswered. Make no mistake, I'm happy to "waste" my time reviewing other people's work, including yours. :-) Saying that less gets done during my absence, just means that fewer patches get reviewed. If the node revision patch (our running example) was tested extensively, I could commit it from Italy. For example, I committed some patches earlier today. However, when I don't have the time it takes to test it (like now), it sometimes goes unreviewed, and hence, uncommitted.
I am pretty sure that these can be minimized. We've had three core committers in the past and it worked.
Not quite. Steven and Kjartan let me review their changes first. Steven only started to commit "independently" one year ago, and even now, he still consults me about bigger changes (and often, I consult him too).
-- Dries Buytaert :: http://www.buytaert.net/
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org