[development] D7 contrib module development

[Daniel F. Kudwien]

> Several problems just keep coming up:
> - modules spamming the watchdog table with E_ALL warnings
> - modules ignoring the style/documentation guide lines
> - applied insane programming(TM) techniques

Go ahead and create patches for those modules.  That's the only way to fix
'em.

> but by far the most serious one is
> - duplication (partial feature overlap with existing modules).

Bad habit of module authors.  Slap them, but create a patch to remove what
has been duplicated afterwards.

> There might be different perspectives on this but IMHO 
> specifically for D7 this is not a good way to go. An example 
> for this mess is the huge number of competing 
> notification/subscription modules for D6 - each with a 
> destinct feature set and of course incompatible to all 
> others.

The reason for that is that someone thought he/she could write something
better, wrote it, and ended up with something that already exists.  From
then on, happy developers continued to improve the pre-existing thingy,
while some others installed the duplicated thingy and advanced on that.  The
end result is: two parties that think either approach is wrong and a massive
croud of users that thinks "And this is why Drupal sucks.(tm)"

Removing the duplication requires that those module maintainers (finally)
come to that conclusion.

> One possible 
> option could be to go some steps towards the linux model, in 
> which all patches have to be signed off by a small team of 
> core developers.

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.

> Drupal would not have to choose an official 
> team of reviewers though - patches could be confirmed by a 
> simple voting system, in combination with the already working 
> automatic testing. The issue tracking system could be 
> optimized for reviewing/auto testing/auto committing patches 
> (more code centric).

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.

> However the specific details: the point of that change would 
> be to shift responsibility (=power) from individual module 
> creators to the coding swarm of contributors. This would 
> significantly lower the odds of b(rainde)ad code getting in 
> and hopefully drastically cut down on duplication.

False assumption: Duplication is caused by braindead code.  Also by
developers who a) are unable to search or b) really want to get another
project on their list to raise their ego.  Cooperation and collaboration
with maintainers of existing projects is the key (which still requires that
you are competent enough to search).

> Especially because of the to-be-expected great API changes in 
> D7 and the resulting amount of code rewriting that has to be 
> done, wouldn't it be a great point in time to get our act 
> together and come up with a single bind-them-all notification 
> framework? _One_ cleverly designed poll/decision extension? 
> Merging/standardizing the various e-payment modules? Imho 
> taking this direction in the long run will result in more 
> coherent code and enable easier adaption to core API changes, 
> also cutting down on user confusion - furthermore increasing overall
> D7 r0xorn3ss!

This mostly depends on the maintainers of those modules.  Because if you
would want to remove the duplication you would have to create yet another
duplicated project.

> What's your view on this?

Somebody circle stomp those developers.

sun