[development] CVS HEAD, code freeze, zeitgeist

[Dries Buytaert]

On 18 Aug 2006, at 02:29, Derek Wright wrote:
> also, given that CCK in core is basically crippled as it stands (no  
> fields) and yet CCK in contrib doesn't work w/ CCK in core, and  
> flexinode isn't going to be ported to either 4.7 or 4.8 (according  
> to ber), i have serious concerns about freezing.  dynamic content  
> types are essential for basically every real drupal site i'm  
> dealing with.  if core isn't going to provide fields, we absolutely  
> *must* have a plan for working fields in 4.8 contrib (and further  
> acknowledge that core basically requires contrib to be functional  
> 95% of the time).

Imagine that the CCK was not in core, and that the CCK in contrib  
would continue to be crippled during the 4.8/5.0 period.  That would  
be an even worse scenario, wouldn't it?

It is pretty clear that getting a proper CCK implementation into core  
is a big task.  It might not be apparent to some, but the past two  
years we've been slowly rewriting Drupal core around the CCK, and  
we're tackling one CCK hack/workaround after another.

It all started with the forms API in Drupal 4.7; being able to extend  
and validate forms was a requirement for the CCK.  Now, in Drupal  
4.8/5.0 we'll have structured body arrays, required to properly  
output CCK node types.  We're also shipping with basic (non- 
extensible) CCK types.  Not to mention various of the smaller steps;  
the ability to rename the 'Title' field to give one example.  Just  
like Drupal 4.7, Drupal 4.8/5.0 will be a huge step in the CCK's  
direction.  We're paving the path and so far we've been good at it.  :-)

There is a certain irony in the fact that the contrib CCK might be  
broken.  Normally, the size and the complexity of the contrib CCK  
should shrink and shrink until, ultimately, there is little or  
nothing left from the contrib CCK.  As a result, it should become  
easier and easier to maintain.

That said, I agree that the current situation is not optimal and that  
we'd greatly benefit from having basic support for CCK fields in  
core.  The reality is that it will probably take another release to  
get it right, and that it will take several more releases to add  
polish.  Of course, you never know.  We still have two weeks left,  
and there is a lot that one can do in two weeks ... (It wouldn't be  
the first time this release cycle that Eaton, jaza or chx come  
forward with a big chunk of CCK code.)

It is dangerous to postpone the code freeze in order to get more  
stuff in core: it takes time to implement this, and as far as I know,  
no one is currently working on a patch to get basic field support  
into core.  If there was a patch and the commitment/willingness to  
finish it before the code freeze, the situation might be different  
depending on the state of such a patch.  Right now, there is no code  
to justify such a decision.

--
Dries Buytaert  ::  http://www.buytaert.net/