[development] Very concerned over Drupal's core development

[Nathaniel Catchpole]

>
>> Another solution would be to split core into two parts. "Framework", and
>> "CMS". The framework would be the things like user, node, block, system,
>> actions, fields, etc., and the CMS would be things like poll, blog, forum
>> and who knows what. The smart thing would be to make "Framework" in this
>> case as small as possible, and push as much as we can into "Framework". Then
>> "Framework" could adopt a nice, long release cycle and focus on big API
>> changes, whereas "CMS" could focus on shorter release cycles upon any given
>> "Framework" release.
>
> I like this idea but it sort of goes into the whole "golden" module
> list that seems to come up ever now and again.
>
> andrew
>

I think the problem is less the number of modules we have in core
(mainly CMS-ish ones), and much more that the ones we have in core are
only there for arbitrary / historical reasons. A patch to add forum,
blog, help, poll, tracker, taxonomy to core now would be almost
immediately won't fixed or stay at CNW for a very long time requiring
years of work to get right - either because there are better contrib
alternatives, or because the code is crappy, or both. However taking
them out requires an upgrade path and a responsible contrib
maintainer, not to mention consensus, and getting all three of those
at the same time is hard too.

On the other hand, getting eternally useful modules like token, CCK,
Views etc. into core is a very long and drawn out process too - for
good reason - if only in part because we know that once they're in
core it's very hard to take them out, and any wrong design
implications have a much longer lifespan and are harder to fix (hence
the main query in tracker module which was bringing Drupal.org down
regularly on Drupal 5 still hasn't been fixed in core for three
releases).

Packaging and better install profiles might help, getting those major
APIs into core will hopefully help us push the old-style modules out
of core eventually as well - i.e. replace tracker.module with a couple
of default views.

I don't think this is the root of the various recurring frustrations
with core development though at all - either those of us very active
in the core issue queue or those who avoid it like the plague. In my
opinion it's a combination of factors, most very hard to fix - hence
threads like this and discussions in #drupal on a regular basis.

Nat