[development] Very concerned over Drupal's core development

[andrew morton]

On Mon, Apr 20, 2009 at 10:03 AM, Robert Douglass <rob at robshouse.net> wrote:
> The other solution which chx and I have discussed, and which is a long time
> goal of mine, would be to reduce the size of core. We carry around a lot of
> modules that don't absolutely need to be part of core:

While there might be specific modules that would be better off in
contrib, on the whole, I think we need to have code in core that
actually uses our APIs. Converting core modules to use a new API is
one of the first and most informative tests the API will get. And
importantly it happens while the original developers are still engaged
and working with the code rather than months later when no one
remembers exactly why a decision was made. I've heard poll.module
referred to as the canary of the FormsAPI because it helps spot subtle
flaws in the API that might have gone unnoticed for months after core
ships.

Back in the D5 beta days I tried to keep the audio module updated for
HEAD to help test it but HEAD was insanely unstable. These days, due
to the unittests, HEAD is the most stable I've seen since I stared
with 4.6 but most of my modules are have enough dependencies on other
contrib modules that it would be impossible to keep them updated.

The one success I've had in this regard was back porting the fixes
that quicksketch did moving the ImageAPI module into core
(http://drupal.org/node/373613) back to the contrib module. There's
been one core bug fixed and another identified. I'm hoping something
similar comes from the push to get ImageCache into core
(http://drupal.org/node/371374).

So while I'm all for reviewing the list of modules in core and
dropping some I think we'd be well served to have several higher level
modules that exist solely to help smoke test our core APIs.

andrew