The "Cache" module is a fork of the "Cache router" module

I stated it as fork because this module borrowed a lot of ideas from cacherouter.

Fork was needed to provide more features.

Added documentation on project page.

What effort did you make to provided patches for these feature requests to the cache router module? Did you even make any kind of effort before forking?

Release notes: http://drupal.org/node/528068

Also, I have reviewed all the issues of Cache router.
These are implemented, fixed, won't be fixed or not important in cache module:

+ http://drupal.org/node/493198 File engine fixes
+ http://drupal.org/node/495736 Unwanted undefined index notice
+ http://drupal.org/node/353815 Cache Router fails - No way to get it working
+ http://drupal.org/node/487920 DB engine fixes
+ http://drupal.org/node/352953 fileCache::delete() passes in wrong argument type for fopen() and unlink()
+ http://drupal.org/node/475788 File engine - Cache write error presented to users. Should log by default and only display for Administrators
+ http://drupal.org/node/467142 hook_theme defined in wrong file
+ http://drupal.org/node/393430 getting some warnings on "db" mode
+ http://drupal.org/node/415930 Can't install in Drupal 6.10
+ http://drupal.org/node/429802 Fatal error: Cannot redeclare flush() in /sites/all/modules/engines/eacc.php on line 202
+ http://drupal.org/node/365065 Refactor Cache::__construct so that it's easy to pass options to cache
+ http://drupal.org/node/383286 Configuration examples for apc and/or memcache engines
+ http://drupal.org/node/365088 Implement a hierarchical (primary / secondary) engine
+ http://drupal.org/node/355624 File engine should not use drupal_set_message?
+ http://drupal.org/node/354534 Bug in create_directory
+ http://drupal.org/node/354554 Wrong calls to file_scan_directory()
+ http://drupal.org/node/318068 Code for a managed memcache engine
+ http://drupal.org/node/279146 Cache router breaks cache tests
+ http://drupal.org/node/463046 APC engine sets timestamps as TTL when not using CACHE_TEMPORARY or CACHE_PERMANENT
+ http://drupal.org/node/266588 Obey "expire" value on cache_clear_all(), like Drupal core
+ http://drupal.org/node/353815 Cache Router fails - No way to get it working
+ http://drupal.org/node/512732 eAccelerator
+ http://drupal.org/node/503914 More info helpful new
+ http://drupal.org/node/341575 XCache causes white screen of death
+ http://drupal.org/node/493498 Memcache and cache_clear_all wildcard
+ http://drupal.org/node/385010 Segfault with xcache
+ http://drupal.org/node/279152 Wildcard fix
+ http://drupal.org/node/330905 APC: Alot of fixes
+ http://drupal.org/node/472864 Deletion warnings in APC
+ http://drupal.org/node/371059 * warning: Missing argument 1 for dbCache::flush()

These haven't yet tested / implemented:

http://drupal.org/node/325921 Error when clearing cache and on update.php
http://drupal.org/node/422250 Integration with Authcache module
http://drupal.org/node/370769 How to use eAccelerator for cache router
http://drupal.org/node/516658 Adding memceched (not "memcache") method
http://drupal.org/node/468844 notice: MemcachePool::set() [memcachepool.set]: send of 32768 bytes failed with errno=11 Resource temporarily unavailable in /va
http://drupal.org/node/347717 File Engine - Add valid file name checking to key generation (Specifically the $appendix)
http://drupal.org/node/384536 Engine "file": "Failed to create directory"
http://drupal.org/node/505910 Logged out in forum
http://drupal.org/node/462844 Enabling Fast Page Caching to Gather Anonymous Page Statistics
http://drupal.org/node/463758 Change module package in info file
http://drupal.org/node/463494 Add support for Zend Cache backend
http://drupal.org/node/434890 encoding break when using file engine.
http://drupal.org/node/381000 Integration with cache_browser module
http://drupal.org/node/398224 Add support for Light Cloud
http://drupal.org/node/374803 Strange behavior using memcached

http://drupal.org/node/531196 file engine does not work on Window
http://drupal.org/node/533696 memory based cache that supports cache_clear_all wildcard??
http://drupal.org/node/458490 Memcache and Cacherouter status

Sorry for asking this dumb question. But what efforts you did to get this patches in cache router module before attempting to fix in cache? There are reasons (stablity is one) it takes a while to get patches commited specially for a technically complicated module like this. From a user perspective I would like to see only one module instead of two.

Cache module has more new features (check project page) that resulted in significant module core changes. This was before fixing Cacherouter core issues, so now we can't simply port changes to Cacherouter.

It would have been nice if you helped get cache router working better instead of creating this. I definitely would have been open to these ideas. This is not the "Drupal way". Taking other projects code, and just laying some features on it is not something that is highly regarded in the Drupal community and certainly not a way to gain any fans here. I know that there are things that need to be fixed in cache router, and this is not the first time someone forked instead of just talking to me. I would be interested in a lot of these changes and so would the 700+ sites already using cache router, why make them switch? If you are interested in helping out with cache router, let me know via the contact form on here.

-s

Hi Mike, Steve.
Well, I wasn't applying to "take over module" (wasn't familiar with that article at that time), I just mailed Steve about becoming module maintainer several months ago, probably you haven't received my mail, Steve.
Cache module is a different project now (Cache Router core changed a lot, I would even say - rewritten), yes it can be merged with cacherouter module, but I think with its newer 2.x branch if it will be available sometime and if that is really needed.

No comments, so I assume my point is right.

No, I think we're just frustrated. We never said you were right. You didn't follow the community procedures. Plain as that.

Ok. I wish just continue my work on the module.

Well, I understand that it's frustrating that I haven't been around to work on cache router, and I don't blame you for wanting to do your own thing, but you have to understand how frustrating it is for me that you're not the first person to fork cache router and it hasn't even had a stable release. I would only give commit access to cache router to someone who provided patches against it and tried to get involved. I have a lot of ideas of where to take it, I just don't have the time to work on it. Someone who is willing to work on it and has shown respect for community procedures would easily get access as a co-maintainer. It is my baby as it's something I conceived and built from scratch. I pulled from several other modules, but rewrote most of the code from other modules. Something that is as similar as cache module to cache router is unnecessary. Any of the ideas that you have implemented mostly came from other peoples patches for cache router.

Cache Router is far from abandoned, but it is on hold until I get time to work on it, or someone steps up that will work with me and my ideas for it. I am open to who that is (could be multiple people), but as far as the future of the module is concerned, I will want to be involved for the lifetime of the project. Even if that role is just an advisory role.

FYI, cache router maintainer has been very active again recently - http://drupal.org/project/cvs/240745

Given that:

(1) We don't need two cache router modules
(2) We want more cooperation between module authors
(3) True, the Cache router module was unmaintained for a while, but we have a community procedure to transfer ownership of an abandoned module
(4) doq has not shown any willingness to cooperate with the author of the Cache router, nor to take over the maintainership of the Cache router module

I suggest unpublishing the Cache module, and kindly ask doq to cooperate with slantview so that the improvements developed inside the Cache module are contributed back to the Cache router module.

Moved to the webmasters queue for consideration.

I agree with Dave, and Damien. To create a fork of a module is not something accepted on Drupal.org; it would be different if the two modules didn't share so much code (but in that case Cache would not be a fork of Cache Router).

If there no objections, tomorrow I will mark the module as unpublished.

I object to marking the module "Cache" as unpublished. With Cache router in limbo, I do understand the reasons for the fork.

Let evolution take care of it.

The code of the module could be helpful for someone at least! I'd like to have it available on drupal.org even if there was mark that it is a fork of cache router.

1. I think about contacting Steve again if he'll be willing to grant CVS access to cacherouter module.

2. Cache started as fork of cacherouter and is no longer sharing lots of code. It may be great if we'll merge two modules:
a) we may want to start 2.x branch of Cacherouter and port Cache functionality to it.
b) we may want to port Cache to 1.x branch and make it backward compatible. Not pretty sure if that's possible and is really needed.
c) Cache module contains some patches (most are not really related to caching) but might be separated to other modules.
d) more work in Cache module is currently done about integrating external locking framework, making it much more Drupal 7 friendly. Leaving it as is.
e) I may mark Cache module as unmaintained (unpublishing releases) and direct user to Cacherouter's page.

doq has consistently shown a pattern of creating modules that do not fit with the Drupal standard: small modules of little use or duplicates of existing modules. That means that your karma, with me and other people, is fairly low. That means I am unlikely to help you if you lodge an issue in a queue I work on, refer clients to you, look favorable on a request for inclusion in Drupal planet, etc.

However, that karma has nothing to do with unpublishing a module just because it is a fork. We have many policies about CVS/project usage and none of them forbid forks. Until and unless our policies forbid forks or duplicate modules (and I hope they never do) we should use social pressure to motivate maintainers to combine efforts rather than more strict actions like unpublishing releases.

And, hopefully for the last time, we should never unpublish a project that has code in cvs. We can unpublish the releases and explain what is going on with the project on the project page, but do not unpublish the project.

Suggest doq "prove himself" by submitting patches to Cache Router, like anyone else would. If/when he has a consistent history of good work, _then_ slantview should consider granting him commit access (not before).

This is exactly my issue. Seeing as that doq has a different direction in mind for cache router than I do, I think I would be willing to grant cvs access if he consistently showed patches and we can evolve cache router in a direction that makes sense to me. Nothing that he added to "Cache" module is tested and stable IMO. I have installed Cache Router on some very large sites like divx.com which do over 20m pageviews per month. I feel that it is finally getting to a stable place and I don't want to add a bunch of untested patches that take it in a new direction besides a stable 1.0 release. People depend on this module for sites where they will lose revenue if they install a buggy module. I would be willing to start a 2.0 branch and have him test out new features there.

My other peeves are that he completely changed the settings configuration in Cache module and for what end? There is no benefit IMO to changing things just because you don't like the way it's being done. If there is a technical reason why the way I did the settings doesn't make sense, let's discuss and change it. If we discuss in issue queue and and collaborate, I would be more than willing to add in wanted / needed features / changes. I'm not going to add to cvs someone just because they have interest in the module. Especially someone who I think doesn't have the best intentions for the module. There have been people like andypost that I would easily add to the cvs access if they asked as they have consistently showed interest and patches for cache router.

I am not trying to be an asshole, but just as in Drupal core, having a single person doing commits and if you want changes you go through the issue queue seems to work well. I have applied many many patches from the issue queue and many people have fixed some obvious bugs I didn't see. I feel like following the model of Drupal core seems to work in this case. I am not opposed to a co-maintainer, but like lyricnz said, I would like some proof that they are going to have the best interest of the module in mind, not just wanting to try out some ideas because they think it's better than the way it's being done. Bloat on a performance enhancing module kinda defeats the purpose of the module. Also seeing that I just released an RC1 for Drupal 6, this module is hardly abandoned. It has a few more kinks to work out before 1.0, but after 1.0 release, I'm willing to start a 2.0 branch and incorporate new changes and features. At that point, we can add in whatever changes people want.

In order for us to get cache router 6.x to a stable release and to prevent my downtime working on client work from preventing a 1.0 release I will consider adding a co-maintainer, I just don't feel it is necessary yet. There is also someone (well respected in Drupal world for performance work) who has contacted me about paid work to get a 1.0 release of Cache Router. If that happens, a lot of these issues will become non-issues.

Drupal 7 completely altered the cache api, and Cache Router will release a new Drupal 7 module that implements CacheInterface classes. This work is not done yet, and I have committed on my module page to the #D7CX commitment. I do not take lightly to that commitment and we will have a D7 1.0 release of Cache Router using the new API. This will need to be tested, and will likely need some new patches.

I made this module as a labor of love the same way we all work on Drupal. I had a very busy summer with client work and was unable to spend much time on this module. I am now back in the swing of things, and I am dedicating a certain amount of time per week to work on this until we get a stable 1.0 release for 6.x and then dedicating that time for the D7 branch.