[development] Re: One core, many distributions

[Ken Rickard]

Sorry 'bout that last one. :-(  Stupid Gmail.

Anyway, we came to Drupal to run BlufftonToday precisely because core is
compact and stable.  The module system is a big plus, but managing
contributions is a big issue.

For our current project, I've been selecting and testing modlues against our
core environment, noting the conflicts (not to pick on one, but, for
example, events.module and sections.module don't play together).

I am acting as gatekeeper for all module installs for the project.  If I
sanction it, we install it.  An officially maintained list of 'approved'
Drupal modules would be a huge bonus for the non-developer community.

At the same time, I think that 'core' should be as lightweight as possible,
even if my list of approved modules is up around 40 or so.  I sort of like
the auto-update from homebase (along the Apple or Mozilla models) but at the
same time think that people who get into Drupal should realize that the
platform takes some cultivating.  You have to pay attention to module
releases, security patches, etc.  That's one reason why I like having
'throttle' in core.  I don't use it, but it reminds me of an important
aspect of site maintenance.

Don't take this as a vote for or against any core modules, (though +1 for
configurable URLs IMO).

I'd also like to second the idea of a community gardener for Drupal.org, who
maintains the list of contributions in a meaningful way (e.g. what modules
have been tested in what environments; what the newest updates are).  Sounds
kinda fun to me.

I'd be for Drupal "packages" of modules that set up common types of Drupal
sites (art, education, projects, news), even if those packages are just
lists of modules maintained by a trusted source.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20051123/ae3b13fc/attachment.htm