I'm confused about one point here. I must confess that although I don't have a lot of experience with Test driven development, I've done some of it and am familiar with the concepts. Are we sure that drupal.org provides automated testing infrastructure for contrib? I don't quite understand how that works given the possibilites of module conflicts and dependencies. If you say it works and can point to an example of a test driven contrib supported by d.o, I'll happily withdraw this concern, but I've always assumed that contrib test driven development couldn't happen, but that contrib providers would need their own infrastructure. Although my own module list of contrib to remove doesn't include comments or aggregator, I'm certainly ok with seeing contrib's removed from core, but I think there's value in having a small set of useful simple modules track with core and therefor get tests run for it (assuming I'm right about testing support). Dave On Apr 20, 2009, at 4:01 PM, Karoly Negyesi wrote:
Hi,
So it seems there is quite some talk about moving some of the core to contrib. This talk comes up from time but we did not have testing and now we do. And that makes a big, big difference, I tell you.
So let's suppose that aggregator gets moved into contrib. Every core tarball still contains aggregator, the latest tag from the DRUPAL-7--1 branch. But the aggregator people can churn out bugfixes as fast as they can and the tests will make sure they won't break stuff. Meanwhile, new features can get into DRUPAL-7--2. Every user can use --2 invidually, core will come with --1 still. Also, they maintain a DRUPAL-8--1 branch and for every unstable/beta/RC they make sure they have ported aggregator and tag similarly as core does (we can punt some of the unstables -- I could understand that not every module gets DBTNG'd immediately it did not happen anyways). Let's list the benefits again:
*) if a company is interested in a module it can grow a community around much easier than with core. They can both release bugfixes and features. *) core does not lose the feedback from its modules
Possible problems:
*) lose of maintenance *) additional burden on these maintainers w/ HEAD compatibility.
Also, aspiring projects can opt for core inclusion (if they accept that a branch can not break APIs and willing to tag along with core) which can be much easier this way. Let's face it, there are much higher quality contribs than the mess called comment module so why not?
There is the small problem of how can people using cvs update core now, do they need to run a cvs up for every directory? Hardly. We can create a 'mirror' which pulls together the commits. This is an easily doable (and yes I am willing to script it).
Regards
Karoly Negyesi