Redefine what's considered a core module

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
catch's picture

So Drupal 6 has been the first release cycle I've been involved with on any level, did a few reviews and submitted some very small patches, and followed a lot more as they went in or didn't. The overriding feeling I've got from it is that the division in core between api and cms-type modules is causing problems that are increasingly hard to deal with. The classic example in this release cycle was the book module patch: http://drupal.org/node/146425 that almost didn't get in, although I'm certain that book.module pre-patch would never have got into core if submitted cold this release cycle either. It also seemed really hard to keep up with HEAD for even quite small trivial patches due to all the multiple re-rolls.

I think a possible answer to this is to slightly redefine what constitutes a core module by splitting each major release into 2-3 core profiles. Only the core-core install would follow exactly the same release cycle as now, the others would be slightly modified.

These names aren't really suggestions, but hopefully descriptive enough, and the specific modules are only indicative, more detail below.

core - api - has only modules which are essential to a functioning drupal site, utility, or provide lots of hooks (update status, search, watchdog, taxonomy etc.). No change from current core except some bits taken out.

core - cms/community - has the basics of a community site like forum, poll, blog, tracker, modr8 etc. + maybe one or two modules that aren't in core but laods of people want (forum access?, w, wy, w, .... you know what I mean ;) )

core - framework - book, views, cck, panels

maybe some kind of 'personal site' one as well.

The idea of this being that everything outside the core - api download gets to follow a slightly different release cycle.
By having their own presence in module downloads, cvs etc. it'd be possible to run x.x-1.x and x.x-2.x versions of these modules. x.x-1.x would be stable/bug fix only the same as core. New functionality could go into x.x.-2.x during the release cycle so more people can contribute and test it and possibly another branch/tag could track HEAD towards the end of each cycle so releases could be synced with betas and rcs.

The advantages are that new features and bug fixes in the cms-type modules could be worked on by a greater number of people, and probably have one or two maintainers with commit rights in addition to the core-api maintainer. This'd make it much easier to work with forum, comment, poll etc. during a release cycle since the HEAD versions wouldn't be entirely broken for half of it, and people would be able to use the x.x-2.x version during a cycle if they wanted to test and use new features instead of waiting nine months for changes to get in.

With cck, views etc. it would solve some of the issues with the lack of distinction between contrib modules, bringing them closer towards core before they actually get included, but still allowing for slightly more autonomous development while they're on their way in. It also opens up the possibility for the views query builder to be a dependency for forum/tracker/blog etc. so those modules could be much more abstracted than they are now. As well as this, you'd get (hopefully) more people helping on the issue queues for them, so that all three profiles get betas, rcs etc. around the same time, meaning more meaningful tests of core beta releases since everything would be ready to upgrade.

So the idea being that what are seen as essential modules would have higher visibility, and a guarantee of no api changes for the x.x-1.x versions, whilst having all the advantages of contrib for rapid development of new features in x.x-2.x. Also things which aren't quite core worthy, but are either on their way in (cck/panels/views) or much demanded (forum access, wy..w, ), get a bit more promotion especially on the issue queues.

Might be a terrible idea but it's been going around in my head for a couple of weeks now, and this new group seemed like decent place to post it.

Finally, a list of modules I think could be taken out of core -api, more than half of them have changed very little from release to release since 4.5/4.6 when I first started using drupal:

aggregator, blog, blogapi, book (until it becomes a menu/taxonomy merged api thing), color, comment, contact, forum, ping, poll, profile, statistics, tracker.

Comments

ooh yeah, +1

dmitrig01's picture

this is great. However core means stuff that comes with Drupal. And how did devel and coder get in to the framework?

Yeah I think core should be

catch's picture

Yeah I think core should be both contracted and expanded to mean those three profiles (which would ideally be three single downloads, I'm not up to speed on how profiles work )- but with those modules mentioned taken out of the core cvs repository for the 1.x 2.x tag reason.

Devel/coder - I guess it depends how much framework is "site building" and how much it's "drupal development" - scratch those then!

This might mean making a new cvs module other than Drupal and Contrib. Whilst mulling this over I was thinking along the lines of Debian stable/testing/unstable and Ubuntu's main, universe and multiverse - different problems but the three-way split could possibly make sense for Drupal as well. Core (required for everything), Core+ (anything included in one of those 3-4 distributions), contrib - something like that.

indeed

moshe weitzman's picture

i think there is a lot of support for this (me included), but not everyone is convinced. i would encourage you to build profiles like this and start showing people your ideas. maybe add some descriptions for each profile, so folks get a sense of how we present this on drupal.org. how would we suport each profile (if anything would change).

OK. I'll take a look at the

catch's picture

OK. I'll take a look at the profiles docs and what's already there, see if I can start drawing something up. New area for me so I'll see how it goes.

I think the only significant change with support would be more centralised security/bugfixing for any modules not currently in core - whatever in cck and views isn't in by the end of 7.x but was in a profile would have to be supported during 8.x. Having said that I don't think it'd be a lot different from now - since no new features would be added towards the end of release cycles in stable branches anyway - just backported security/bug fixes.

Also it'd have to be clear that using the unstable/new versions of modules wouldn't be subject to the same level of support as those included in core distributions - that could probably be handled by keeping them at beta/rc until they're included in the next release. There's also the chance that a development version could span two core releases (i.e. 7.x-1.x (core) 7.x-1.x-dev - 8.x-1.x (core) 7.x-1.x (beta/rc) - 9.x-2.x (core with upgrade path) - to me, that's a good problem to have, and better a 'postponed' module with new features that people can use and test and refine than a postponed patch.

Exhibit A: Remove poll

Slice and Dice

RobLoach's picture

I'm all up for removing functionality that would have a better life if they survived in the contributions CVS as opposed to the Drupal core CVS. This would give those modules a more frequent release cycle, as well as give them some more innovation than what they get while in core.

Boris Mann's picture

We can always backport functionality into, eg. install_profile_api, for the D6 cycle.

I didn't have time to work on this for D6, but D7 gives us the opportunity to experiment with this. If we do want to get it into core, well, then we should start with current core, potentially with a "we also recommend modules x, y, and z", or some way to add that package as an add on.

Adrian has some ideas on the install profile code for D7 and ideally will be able to spend time on it.

The larger proposal of what is core and splitting things up is a MUCH larger discussion.....and seems unlikely to me. The starting point for install profiles / what is core -- is defining what you are trying to build: personal / pro blogging community, small business CMS, web app framework, etc.

This post is a little old

catch's picture

This post is a little old now so I've changed my views on this slightly, however I'd still like to see a few modules on that list living outside core :)

As to install profiles I think there's a couple of things we can do.

During usability testing, some of the users kept asking for examples of different things - imo a good start for that would be providing an install profile with 3-4 content types, each with a handful of nodes, a couple of differently configured taxonomy vocabularies with a handful of terms in, none of this being targeted at any particular kind of site, just a jumping off point so you can edit or delete stuff rather than starting from a blank slate. That way users can see how taxonomy terms are attached to nodes, maybe see a small book hierarchy, primary links - stuff like that - the first time they log in as an admin. The idea being not to give users a template, but to have a hands on conceptual model of how Drupal works a little faster than currently happens.

At the same time, that'd be really annoying to deal with every time you start a site - so I was thinking about two install profiles - a 'default' which would have all that stuff added to it, then an 'advanced' profile which is pretty much empty - just gives you core with zero modules, zero node types etc. (or we could make the 'default' empty/leave it as is and make a new 'quick start' profile - either way it works out the same).

Otherwise I think a blog or community install profile is best developed in 6.x contrib so it gets some users, but would ideally also track HEAD (and possibly pull some dependent contrib modules along with it) so it can be dropped into core at a later date. Although I'd like to see some modules out of core, I'd also like to see other stuff go in if it means we could have a well featured blog install profile to rival other offerings. What I wouldn't want to see is a blog profile that falls short of what a regular user can configure in half and hour by themselves - which without commonly requested stuff like pathauto, wysiwyg etc. would likely be the case, and imo do more harm than good in terms of perceptions. Better nothing at all than 'drupal for bloggers' which everyone slags off and we're stuck with for a year.

excellent ideas

Keith Hinkle's picture

I'd like a conceptual model for custom views and blocks that use them.

I'd also like one for TAC vs OG for enabling delegated authorities.

Lastly, a model for moving configs from dev, to test, to production and removing if that exists.

One interesting thing is

merlinofchaos's picture

One interesting thing is that Views + Panels best feature is the fact that they can be put entirely into code. Panels can be used to replace the 'page' node, meaning you can put your site structure into code, rather than into the database. That means you can modify your panels and views on a dev site, export them into code, and then do a code push.

It doesn't answer every problem of moving config to dev/test/production, but it helps.

Sounds interesting

yched's picture

Panels can be used to replace the 'page' node, meaning you can put your site structure into code, rather than into the database
Sounds interesting, but I'm not sure I get it. You mean having the 'page' node type be handled by 'panels as nodes' ?
Could you elaborate a little ?

I mean...not using nodes at

merlinofchaos's picture

I mean...not using nodes at all, but putting site structural pages in panel-pages entirely. You can use a 1 column display with a custom pane to sort of emulate the basic functionality of a node.

excellent ideas

Keith Hinkle's picture

mis-posted; intended as a response to a comment.

Views Developers

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: