If the community gets collectively pissed off, everything falls apart. If we as community take the decision to change the process, why would that piss us off?
That some modules get ported anyway makes them more obsolescent than obsolete - but unless all the maintainers provide rock-solid migration paths (much harder than a port), there's not much to do about that. Well how is that impossible to achieve after having settled on new framework designs? It's just a simple matter of converting DB fields isn't it.
Most of our major contributors didn't start off in the Drupal community fully formed and descended from heaven, even chx and merlinofchaos. In terms of core contributors - I''m credited with a lot of patches against Drupal 7, I pretty much learned PHP reviewing and writing patches against Drupal 6. If my interest was in contrib rather than core, your new rules would've been a major barrier to getting involved. How does preventing bad code from landing in the repository make it harder for you to get involved? Why is it not possible to erect a support system that facilitates easier reviewing and testing of code not in the repo.
Fortunately anyone can upload any patch they like to the core issue queue, getting beyond that is where it takes a lot of effort. To make the same apply for non-core modules is what i am proposing. It seemingly didn't stop you from becoming a drupal developer, did it? Would you rather have seen any code submission from you have been committed without those checks? Then why should that be the case for non-core modules?
Have you looked at Drupal 7 yet? Very sporadically. I've installed it, from time to time looked at diffs and the changelog. How familiar are you with the core development process? Well i know it sometimes takes years to get stuff in *g
While I'd love to see some consolidation in contrib, I don't see any realistic proposals for handling this, rather than mythical hordes of people who'll magically appear to review patches for contrib as well as core. It all stands or falls with accessible support interfaces and good operational algorithms (i've made a detailed proposal but noone picked it up).
I'd love to see code quality metrics (both coder and test coverage) for modules, and that combined with usage and other metrics. With that, the unmaintained modules will naturally get filtered out to the bottom. The unmaintained modules are not really much of a problem. What my proposal is targeting is mainly the situation where duplicate modules are seeing continues development with diverting trend, instead of merging. That's the hardest issue to solve, and now is the time to try. Why now? Because the D7 non-core development cycle just started. Anything is possible now. When all modules have migrated from D6 to D7 we will basically have perpetuated the situation to continue through the whole D7 cycle.
Please have a look at the attached graphic which is an excerpt from this lecture 'Quality Management - Quality and Economics': http://www.wzl.rwth-aachen.de/en/ebecb2e7d199a686c125736f00454c10/04_l_eng_q... ..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
