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