Change requires to take some action. That's what me taking the initiative was all about ;)
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. We have several handbook pages that outline coding standards and best practices. You can simply put it this way: Developers who do not adhere to them do not want that anyone contributes to their modules. To be realistic, we can't regulate more than regulating that any code in CVS is licensed under GPL. Yes we can. We can set up a clearly defined landing path for code submissions.
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. ...which prevents innovation. At least one of my modules would not exist today if it would not have gone through 1 year of quality assurance and testing, becoming one of the most popular Drupal modules in the end. Does not. A lot of stuff has been tried already for D6 - for D7 everyone and his dog should have made the experiences from which we can benefit, especially about which design decisions cause maintenance problems later one. So in my opinion the concern you voice is valid even for D6, it would have stiffled innovation to regulate code committs. But for D7, i believe the goal should shift from having a huge quantity of modules to expandable frameworks for areas like notifications, polls/web forms/questionaires, payment that provide coherent and flexible APIs to obliterate fuplicate attempts of providing the same functionality. If it takes a lot of time to migrate certain modules from D6 to D7, and just as much time to implement a totally new module for D7 which merges functionality, code and vision of several modules, i (as a student of engineering, specializing in construction and development) *very very very* strongly would support the later choice. It might be difficult and require changes, but in the long run it will be worth it.
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? The issue is not the tools, but the brains and time of contributors. Each and every module needs people who "love" a module and can spare a fair amount of dedicated time to think about and work on a project. Yes and no. Each piece of code needs to be written by someone who needs the functionality AND is passionate about it, ACK. But that should not inherently make him the person to solely be responsible for the code. Instead, every code contribution should be subject of a community process in which everyone caring about it reviews and contributes, without defining single individuals as maintainer of a module (though recording the credits for each individual submission).
Improvement and innovation requires in-depth knowledge about something. True. How does a more swarm-like approach to code committal hinder that? That'd just channel the flow more tightly.
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. We have this system already. It is called "co-maintainers". Well it doesn't systemicly solve the problem, as it really just expands the number of stressed individual developers who have responsibility instead of tackling the root cause that makes all this even possible: no enforcement of coding standards, no wider review of changes before committal, no opportunity for improvements to be made before committal, single individuals responsible for decisions.
To clarify here's how it could work: - erection of drupal-patches mailing list for all code to pass through - coupling that mailing list with a revised patch tracking system - patch submissions to the ML create a patch issue - comments to the posting get also attached to the issue - in turn, patch issues file through the web interface are echoed on the ML, just as comments to it (similar how to what the mailman/mailhandler modules.. i hereby step up for a clean reimplementation of this functionality) - inserting a voting system into the patch issue tracker - two choices: 'ready to be committed' or 'veto' - core developers' votes get higher weight, can clear 1/2 veto votes - having the patch issue tracker DISPLAY the code by default additionally to providing it as attachment - setting up rules and regulation (proposal) - developers get awarded D7 svn rights by either landing more than 1K of code or 10 commits in core, or by being promoted - all code *has* to be either committed by these developers or has to get 10 RTBC votes with no vetoes - all code going in has to at least break no tests AND - all code is automatically tested for adherence to coding standard - patches can -and should- be improved by all who care until 10 RTBC - code contributors are recorded in each modules changelog / AUTHORS - several frameworks have to be put in place for D7: - messaging / change notification - polls / web forms / questionaires / quiz - translation (l10n server integration, finally!) - caching - media integration - probably e-commerce/payment => brainstorming in the corresponding groups needs to start Of course implementing this would require messing with the ways of some drupal developers, and it will definitly slow down the rate of contrib code increase. However, in the end, you get what you pay for! To explicitly say it again: all this is only viable because of the experience gained from D6 unregulated contrib development creativity. But looking at how *quality* is at the top of the D7 agenda, it might be a wise idea to apply more pruning and gardening tactics in general also to the modules to _not_ end up in an impenetrable jungle thicket like the D6 contrib area. And swarm intelligence is just the right buzzword to do it.. Webchick, Dries, core devs: pleace voice opinion NOW ;) rgds marcel. -- "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