[development] Very concerned over Drupal's core development

[Robert Douglass]

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>  
> wrote:
>> 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.
>
> Gábor

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  
Simpletest framework.

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.