[development] D7 contrib module development

[Daniel F. Kudwien]

> Dude i've been wasting my whole summer on that. Cleaning up 
> afterwards 
> is a hell lot of more unrewarding work than preventing the shit from 
> hitting the fan.

100% of all other contributors are "wasting" their time (not only the past
summer) to improve Drupal core and contributed modules.

Change requires to take some action.

> > Bad habit of module authors.  Slap them, but create a patch 
> to remove what
> > has been duplicated afterwards.
> Yeah like i even have multiple days each day - sorry i simply can not 
> fix stuff beyond the needs of my NGO site.
> If the development process allows module authors to have bad habits - 
> well maybe its not tightly regulated enough.

We have several handbook pages that outline coding standards and best
practices.  You can simply put it this way: Developers who do not adhere to
them do not want that anyone contributes to their modules.

To be realistic, we can't regulate more than regulating that any code in CVS
is licensed under GPL.

> > Removing the duplication requires that those module 
> maintainers (finally)
> > come to that conclusion.
> That seems far less realistic than setting up a strict regulatory 
> bottleneck for every line of official core/contrib D7 code. Take a 
> look at how extremely discerning the benevolent dictator of the Wine 
> project - Alexandre Julliard - handles the many code submissions from 
> wine-patches - and at the resulting quality. There's a reason 
> he skips 
> committing 30% of patches.

...which prevents innovation.  At least one of my modules would not exist
today if it would not have gone through 1 year of quality assurance and
testing, becoming one of the most popular Drupal modules in the end.

> > Core developers are already buried with core development.  
> Take a look at
> > issue queues of "sub-core" modules like Views and you'll 
> understand that
> > each project needs its own code-guards.
> That very well i know. Maybe we can all improve the process and 
> optimize the obligatory set of tools?

The issue is not the tools, but the brains and time of contributors.  Each
and every module needs people who "love" a module and can spare a fair
amount of dedicated time to think about and work on a project.

Improvement and innovation requires in-depth knowledge about something.

> > Machines can not (yet) replace the complex thoughts and 
> decisions of a
> > human.  If a patch passes some (human-created) tests, that 
> only means a) it
> > passed an expected behavior (which still can be wrong or 
> outdated) and b) it
> > passed coding-style tests (if there were some) - but there 
> still has to be a
> > gate-keeper who tells you about logic errors and the future 
> of Drupal.
> Of course not - but if the automated tests pass, AND 10 registered 
> Drupal developers okay the patch by voting RTBC - for sure a commit 
> bot can take the decision to just do it?
> My guess: swarm intelligence + sophisticated tools outperform 
> stressed individual core developers.

We have this system already.  It is called "co-maintainers".

sun