This ties in with a few things I've been thinking about recently. I posted something on groups a while back that's along similar lines: <a href="http://groups.drupal.org/node/6143">http://groups.drupal.org/node/6143</a><br>
<br>Couple of updates to that:<br><br>At the unit testing BOF in Boston, Douglas Hubler brought up one possibility opened up by having core covered by testing. When there's a high level of test coverage, it ought to be fairly easy to maintain a development version of smaller contrib modules as soon as code thaw starts, have tests for it, run those tests every couple of weeks, and then be told exactly what APIs have been broken week by week.<br>
<br>Have a couple of dozen modules maintained like that, and you'd be able to run skeleton sites using a few contrib modules on HEAD all the way up through to Beta and RC (obviously with no content upgrade path). The more APIs move into core, the more of contrib could potentially do this. This combined with packaged install profiles would release a lot of the need to keep modules in core - since we'd have regression tests (== poll module) in contrib being broken every so often during the release cycle to keep us honest, and an easy way for new users to get started with some basic modules that could potentially be ready at the same time as core moves to RC. This has a decent chance of improving upgrade documentation and automated tools like coder as well - meaning less of a lag between major releases and contrib upgrades.<br>
<br>In terms of the lack of reviews in contrib, IMO this is an issue that needs more discussion.<br><br>I don't maintain any contrib modules, none at all, but I try to help out on the issue queues for ones I use. Even though less people use contrib modules than core by default, the number of eyes on the queues for big modules like CCK and views is proportionally much, much lower.<br>
<br>Additionally, lots of traffic about modules (including bug reporting and fixing) happens in the support forums rather than issue queues and gets lost there. I know sepeck is in the process of reorganising the forums - which will include more pointers to individual module issue queues for that sort of help - and it'd be good long term to get module-specific questions (and answers) out of the forums so they're kept in one place. Something that might help with visibility for support requests in contrib would be an "open support requests" link from contributors links to encourage people to help out on modules they don't personally maintain - similar to the function 'new forum topics' has now. This means moving real people from the forums to issue queues - if even 10% of the people who move are those who already answer questions and test fixes in the forums - it could mean many, many more reviewers both for core and contrib (and possibly less work for module maintainers rather than more).<br>
<br>On Views and CCK - I think the APIs need to live in core at least. Core currently has to implement a bunch of stuff that CCK and views does (fields, formatters, lists of stuff all over the place) - so unless we can have core depending on contrib, it's a lot of duplicate code. Whether that includes the UI for adding fields and creating new views is a different matter.<br>