[development] best pratices, test environment, patch review: clues how to make easier to contribute

[Ivan Sergio Borgonovo]

On Thu, 14 Aug 2008 23:30:50 +1000
"Ryan Cross" <drupal at ryancross.com> wrote:

> On Thu, Aug 14, 2008 at 10:53 PM, Ivan Sergio Borgonovo
> <mail at 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