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