[development] Very concerned over Drupal's core development
rob at robshouse.net
Mon Apr 20 16:40:58 UTC 2009
On Apr 20, 2009, at 6:13 PM, Gábor Hojtsy wrote:
> On Mon, Apr 20, 2009 at 6:03 PM, Robert Douglass <rob at robshouse.net>
>> So, in my opinion, if you want to take Drupal to the moon, you do two
>> things: 1) give more people the keys to the car, and 2) shed a
>> bunch of the
>> pieces that we currently call "core".
> Would that solve our other problem: that many contrib modules got
> updates later, so it turns out after a stable release that certain
> APIs are not complete or suitable for important contrib stuff? If we
> move more of the modules which use these APIs outside of core, we go
> to pure API design without validation of those APIs with real life
> modules, no? While I agree some modules would be best to go, maybe
> moving all is not the solution. Poll was joked to be one of the best
> API validation modules (for drag and drop, AHAH, etc). While that was
> a joke to some degree, it also has roots in reality.
I agree that your concerns are valid, but I think that solving those
concerns would be easier than solving the larger core concerns raised
by chx if we continue to follow the exact strategy that we have now.
API validation is vitally important, and should be driven by contrib.
Contrib should be instructing core "hey, I need this in the API so
that I can do what I want". Contrib module maintainers currently
submit patches to core to tend to the important APIs that affect their
modules. Witness Earl Mile's recent patch that has major ramifications
on future Views development. http://drupal.org/node/322344
Contrib modules are real modules. They do a fine job of finding the
limitations and strengths of core's APIs. The feedback loop from
contrib to core is there, and it is strong. In one direction. Most of
that feedback currently sits idle in the core issue queue, however,
and contrib module authors often choose to just work around core
instead of enhancing it.
Poll, despite being "core's regression test", is the best example. The
only time anyone pays any attention to poll module development is when
other people scream "get poll out of core!" loudly enough :P These
days, if we need regression tests, we should put them in the
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.
"CMS" would get a new set of "core" committers.
More information about the development