[development] D7 contrib module development

[Marcel Partap]

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