[development] CVS HEAD, code freeze, zeitgeist

[Darrel]

Dries Buytaert wrote:
>
>> Yes. In fact, I beleive the only solution is the other way around: 
>> Release
>> with less stuff in core. The less changes, the easier it is to keep 
>> in pace
>> with all our contribs. And in the same time, put less pressure on 
>> upgrading.
>> If stuff (contribs) is not ready, we should not tell people to upgrade.
>
> We had this discussion before, and I still disagree.  I believe that 
> CCK+view is what the next generation of open source CMSes will look 
> like.  They have the potential of being the heart of Drupal.  For 
> Drupal to get to the next level, they have to be in core so that 
> everyone can rely on it as well as build on it.
>
>> This particular field feature, however requires a big rewrite for 
>> CCK, again.
>> If CCK would do it *properly* (see above), it would mean a big 
>> rewrite to
>> remove of one of the core concepts in CCK: making nodes. I suspect 
>> this might
>> mean a complete rewrite, after all.
>
> Please elaborate.  What would you rewrite, and why?  What is not 
> properly done in core that is a showstopper for full CCK support?

This is what an offhand look at content.module suggest  needs to be done 
to me...

1) Everything done in content.module to date as far as node type 
creation  needs to be stripped out.
2) the field specific  menu items needs to be integrated with the new 
node.module menu.
3) content_node_info, content_access go the way of the dodo, superceeded 
in node.module
4) integrate content.modules node hooks using hook_nodeapi
5) titles on forms need to be moved into node.module, and out of content 
type modules.(seems like they already should be but page.module
   sets $form['title'] along with the other node type modules.

There a no show stoppers here, except maybe removing title fields from 
the forms in node type modules since they are handled by hook_node_info 
&& node.module sets the label accordingly.
>
>> So this leaves us a long period in 4.8  with 1) a hacked up, patched up
>> flexinode and 2) a heavy under development replacement for it, CCK. 
>> None of
>> wich I would advice any (sane) person on his/her production site. 
>> Result:
>> another release without a production-ready system for dynamically 
>> build (with
>> fields) nodes.
>
> Note that there are 3 systems here: (i) flexinode, (ii) contrib CCK 
> and (iii) core CCK.
>
> I can't speak for (i) or (ii) but if they are "hacked up" then their 
> maintainers are to blame -- at least to a certain extend.  I can only 
> speak for (iii), and I think you're overly pessimistic about it.
>
>   1. We made an almost insane amount of progress since Drupal 4.7, and 
> we might make more progress by the time we freeze the code.  (Go 
> folks, go!)
>
>   2. The lightweight CCK that is in core is fully functional.  Sure, 
> you can't add extra fields yet but there are many valid use cases 
> where you don't need additional fields.
  the important part of cck is that you can have fields... right now you 
just have flexible node naming and node type creation.

>   3. It is probably at least another 2 months until Drupal 4.8/5.0 
> gets released.  That means that there is plenty of time left to fix 
> (i) and (ii), and to a lesser extend (iii).  It's only 3 months since 
> we released Drupal 4.7, and it is another 2 months until we might 
> release Drupal 4.8/5.0.
maybe fields.module will be working by then... I'll see if I can get a 
head ready field.module together today if JonBob hasn't already.

>   4. The work we have done in CVS HEAD should be beneficial for (i) 
> and (ii) so I'd like to believe that these modules become less "hacked 
> up".
I don't think there was enough public communication between the people 
working on cck and cck's inclusion in core, to allay FUD. I had a lot of 
it until I just dug into content.module to see how the changed in core 
actually affected it, and how hard they would be in to intgrate, and its 
not as bad as I suspected.. There still remains a question of whether we 
modify node_load to contain content.modules node hooks, or do it through 
nodeapi....  integrating it all into node, would make core a bit fatter, 
but would get rid of a layer of inner loops. My personal opinion is let 
field.module live on its own using node api until field type modules 
mature. We can look at moving the rest into core after the next release 
if it's deemed a good idea.

>> I don't see this as a reason for postponing a code freeze. But I do 
>> see this
>> as a reason for concern in a more general way. Especially since the 
>> problem
>> seems to become structural. with the rapid growth of Drupal one would 
>> expect
>> the overal quality, amount and feature-richness of contribs and 
>> themes to
>> improve. I don't see this happening ATM! discussion at drupalcon? 
Its no reason to stop the code freeze, but some 'improvements' may 
appear to be hinderances.  Especially since no one to date has taken the 
time to express to the community as a whole how simple the modifications 
required to content.module to create field.module really are.

.darrel.