[development] Drupal as an API: where the value is ...

[catch]

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:
http://groups.drupal.org/node/6143

Couple of updates to that:

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.

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.

In terms of the lack of reviews in contrib, IMO this is an issue that needs
more discussion.

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.

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).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080327/35ab25dd/attachment-0001.htm