On Apr 20, 2009, at 6:13 PM, Gábor Hojtsy wrote:
On Mon, Apr 20, 2009 at 6:03 PM, Robert Douglass <rob@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.