Roadmap to RC2 [#698480]

Let's summarize here all critical issues to make stable release

This related both for DRUPAL-6 and DRUPAL-5 branches

After spending a lot of time reading through current issues I realized

1) file-engine is broken in current RC1 so lets focus on
#578522: File engine: Performance, filenames, and other cleanup
#588820: Creating severe load on system by logging thousands of unlink errors in DB log

2) There's a some class conflicts #564460: Class conflict, namespace collisions
We should take D7 approach with class naming to prevent this

3) There's a big trouble with locking in APC and memcache which have no own
- Memcache should be synced with memcache module or rolled back to beta9
- It's a good idea to try implement php-semaphores http://php.net/manual/en/book.sem.php or any available on

4) We need some UI #448274: Cache router wont show up in the Administration menu
- for 1.0 version seems enough < ahref="http://api.drupal.org/api/function/hook_requirements">hook_requirements()
- do we really need statistics?

5) there's a lot of documentation issues - configuration of this module is too hard or bad described
My English is not good to write docs - Any help is welcome

Comments

Comment #1

andypost

he/him

Russian

CreditAttribution: andypost commented 28 January 2010 at 23:13

We need to fix tests for drupal6 #698276: Tests for module

For Release I'm planing to implement #463494: Add support for Zend Cache backend

there's a lot of info in #245341: Unthrottled while loop in memcache engine causing high cpu utilization.

Drupal 7 #593238: Do not release Drupal 7 version of this and move the engines into separate projects

Comment #2

slantview CreditAttribution: slantview commented 29 January 2010 at 01:05

Updates:

1) #588820: Creating severe load on system by logging thousands of unlink errors in DB log - This issue has to do with #3, NOT with file engine specifically. There are troubles with file engine, but I think we need to look at how we are implementing this and how we should change it. It was originally copied from fastpath_fscache module. That module looks abandoned. We can re-write some parts of our current file caching make it work well. I am very much ok with the first patch though I haven't looked at it much.

2) I'm totally ok with this as well. I would say let's using the naming convention from D7 as well and change it for all of the branches.

3) I think the current implementation of locking in Memcache is ok with the exception of figuring out how to do a versioning and not waiting on the lock for so long. APC and the rest of the opcode/memory caches should be reverted to beta9 version and worked out from there (just add back the lock/unlock functions into the classes). I think PHP semaphores are a little overkill however. I would say we should just figure out a consistent strategy to have atomic locks, that is why i tried out using file locking, but for the long run, i would say lock with whatever the technology is, or go back to using the database for that (see lock.inc for D7).

4) Yeah, this is so highly debatable. Because we can't consistently get stats from all of the backends, I would say we go with the stats from the least common denominator and just get at least some basic stats. There should be something. This should be version 2.0 however.

5) Since you are working on getting some of this fixed, I can work on documentation. Let me know what kind of documentation we should have. I can fix the readme file and figure out how to get some of this stuff documented.

As far as Zend Cache I'm not too worried about a Zend backend for now, and I almost feel like we should wait for a version 2.0 for that. I don't want Zend to hold up a 1.0 release for this. We can start a 2.0 branch as soon as we get 1.0 out.