[development] FAQ: Why is Drupal still using CVS when X is a much better choice?

Nathaniel Catchpole catch56 at googlemail.com
Thu Aug 7 14:56:22 UTC 2008

 Ivan Sergio Borgonovo wrote:
> It doesn't seem that less coupling between the "community plumbing"
> aspect and the project management infrastructure is having an
> appreciable effect on other project flourishing of extensions.

For me there's several reasons why the centralised project*
infrastructure is an extremely good thing.
In most cases, other projects don't have modules which are in any way
as interdependent as Drupal's - not just CCK and Views, but modules
like Token, VotingAPI, imagecache and suites like ecommerce and
ubercart where there's a tonne of dependent modules as well, many many
others. Having all these in one place is a massive benefit, and
encourages inter-project collaboration.

Another issue is that if you use a popular module and the developer is
hit by a bus, then assuming it's used by some other people with enough
experience to take it over and enough of a need for it, there's a fair
chance the module will be adopted by a new maintainer - not on some
random website that you might find via searching a year later when
you're looking to upgrade, but right in the same spot. This is in
contrast to jQuery plugins where there'll be a howto on one site,
followed by a plugin on another site, then a different version of the
plugin on someone elses site - none of which have clear version
compatibility - I use jQuery as an example because they actually use
project* on jquery.com for the central project browsing minus the CVS

While core development is a very different process from contrib,
nearly everyone pointing out how different it is has failed to mention
that almost as many people contribute core patches as have CVS
accounts on drupal.org - for some their patch is their one and only
contribution to Drupal before disappearing again. Not to mention core
uses exactly the same infrastructure as contrib for packaging etc. -
meaning the infrastructure work would be about as much.

> I wonder if sec team actively scrutinise contrib modules or
> just coordinate fix in core and sec announcement for contrib.

The sec team doesn't go reviewing random contrib modules - there's
about as many contribs released per day as there are security team
members, however there is active support for security issues in
contrib  once reported, so it's more than just releasing an


More information about the development mailing list