On Thu, 14 Aug 2008 23:30:50 +1000 "Ryan Cross" <drupal@ryancross.com> wrote:
On Thu, Aug 14, 2008 at 10:53 PM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
There is not a compact knowledge base of several techniques that may make more profitable for people that already maintain drupal sites to contribute to core and contrib. I think that most developers are still applying common wisdom and their own hand made recipes.
Actually, there is.... http://drupal.org/patch/review
again not correct..... Setting up a test environment to review patches: http://drupal.org/node/28245
The only major thing I see that differ from what I consider a naive approach is to name "label" the copy with the issue #. That setup is not going to test if everything keep working on a multi-site setup or with some prefixed tables. I'd consider interesting to include in the test some popular modules... or include some modules that just "test" a set of core API. It would be nice to share some more wisdom like Larry did about development environment. I think teaching how people can manage and integrate their everyday job and patch review/patch contribution could help a lot. eg. there are patches that are still waiting to be applied but that are required in certain environment + people maintaining their own modules. So the process to test a patch for some people may become: * keep a set of internal patch to Drupal core. * install Drupal along with some "interesting" modules as multisite + db prefix + some data produced by devel module * get Drupal HEAD * apply internal patches to core * apply issue queue patch * restore "clean" test db Now I'll gain another bit of unpopularity. If I use Drupal, I've to patch core, my patches are seldom committed but I've no easy way to check if other patches play nice with mine... I'd prefer the status quo. Reviewing doesn't look as an interesting activity... my focus will be on "when do my patch get into core" and "how do I handle next core/module update?". If on the other side reviewing patches is part of my everyday job (eg. I review changes from colleagues in my drupal shop already) a) I'll see more patches approved including mine b) I won't suffer the "task switch" effect Kathleen was mentioning c) I'll work in a uniform environment when developing my modules/core patches and an uniform environment similar to the one used by other developers making communication easier. I'm not saying someone has to be blamed. I just would like to see more discussion, learn more etc... I think there is still a lot of hidden wisdom about best practices and coming up with some sort of standardisation may lower the learning curve and provide a common dev environment that could make testing, applying patches and communication among dev easier. As Kathleen and Chris pointed out we miss a common pattern for "test patch files" in a more complex development environment (think about Drupal shops). I'm not sure if this is lack of infrastructure as you pointed out or lack of common best practices that are suited for more complex environment than just a plain Drupal install and a patch at a time. Or maybe I'm just too optimist and I believe that there should be a way to make all this a bit easier. Maybe all this fuss will help me to accept it's not going to be easy, accept that in certain environment a patch review is going to cost more than 20min and concentrate on work that can actually be done in spite of wasting time trying to turn lead into gold. I just would like to know what others think and how they manage their patch/review env when it get more complex. BTW I get an access denied here http://drupal.org/node/283840 BTW2 among the list of interesting documents I forgot to add other than /review there should be also Drupal coding standards. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it