[development] D7 contrib module development

Marcel Partap mpartap at gmx.net
Sun Mar 8 03:26:19 UTC 2009

On 08/03/09 03:57, Daniel F. Kudwien wrote:
>>  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.
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.

>>  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.
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.

>>  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.
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.

>>  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.
That very well i know. Maybe we can all improve the process and 
optimize the obligatory set of tools?

>>  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.
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.

>>  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).
Well of course it is the key, and the docs have been endorsing it 
since years. In reality.. well uhem http://drupal.org/node/197093 
cough cough..
Ok fine maybe it is more practical to set up an development algorithm 
*for D7* (not D6, everyone can still go bonkers there) that leaves 
less freedom for 'stuff' (communication, decisions) to 'go wrong'.

>>  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.
You can call it duplication - i'd prefer talking about rewriting and 
merging. Key focus should be on clean design, flexibility and code 
efficiency - just the values that are relevant to D7 core development.

>>  What's your view on this?
> Somebody circle stomp those developers.
Will that make the problem vanish? Or maybe it'll just annihilate 
precious programming talent.. X)

  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future

More information about the development mailing list