memcache support is a key performance tool, and arguably critical-infrastructure, for "high-performance" Drupal; no surprise to anyone.

Although D7 is released, the module's D7 version appears to have lots of work to do. A timeline for 'production ready' is unclear at best.

Without it, production deployment of high-performance D7 + memcache is not an option for many.

When community devs are asked about 'when', a frequent answer is "we're doing it for free ..." and the usual etc etc etc ...

An end-user client with money to spend has attempted to contact a number of the 'larg-er/-est companies' in Drupal space, to see if they'd consider, as well, contrbuting resource/direction to this modules' development.

One reportedly responded effectively -- 'we can't get involved, the community will push back'.
Another seems to have forgotten that it's good business to actually return phone calls when there's a client that wants to spend money with you.
I.e., not going so well.

Is there *any* mechanism viable-in-and-acceptable-to community for aggregating funds/resource targeted at this module, and memcache support in general, and getting it to full, D7 production-ready status *much* sooner rather than later?

Comments

catch’s picture

catch
he/him
Primary language English
commented

I am a bit surprised by the response you got from that company (which I assume will remain nameless), companies are happy to use GPL modules as part of sites which clients are paying for, so it seems very odd to then turn around and say they won't help with funding development of that module because it's open source. FOSS is about software free at point of use, while it often gets produced in people's free time as well, that's not what makes it free software.

Most of the pending issues against 7.x-1.x currently are the result of work on the Drupal 6 version of the module by Tag1 Consulting, which was funded by Acquia. We did not have budget to apply everything to Drupal 7, so outstanding issues from that sprint are at 'to be ported' status - and contain a mixture of bug fixes and new features.

Normally we'd make changes to the 7.x version first then backport, but the 6.x-1.5/6 releases contained some regressions which needed to be fixed urgently, so we switched the focus of development back to 6.x to stabilise - and it is easier to have patches going in one direction than both.

The 7.x version is in use on some large Drupal 7 sites (and has been for nearly a year in at least one case), however I wouldn't be happy releasing a release candidate until it's in sync with the 6.x branch (especially for sites that are upgrading from 6.x to 7.x since there are new features in 6.x that aren't in 7.x yet).

Overall, the module is likely to be 'stable' before there is a point release - since most of the outstanding issues are discrepancies between the branches (even some of the bug reports in the 7.x queue we mainly moved there to verify against that branch and may not be active bugs). It would be worth testing the module and seeing if it's sufficiently stable for you - there have been very few bug reports against the Drupal 7 branch in recent months. Clear bug reports (or confirmation of stability) may help move things along. Also note that project usage statistics for memcache are inaccurate - since if you use the cache, lock and session backends, but don't install the optional modules, they don't get reported back to Drupal.org at all - so the usage stats aren't necessarily a good indication of D7 uptake.

In general both Jeremy and I try to respond toRTBC patches in the queue or new bug reports promptly, but my free time tends to get spent on core so it is unlikely I'll end up doing concentrated work on the Drupal 7 branch until it's needed for a client or there is direct funding.

Tag1 would definitely be happy doing more funded work on the module and working towards a stable D7 release, the easiest way to co-ordinate this would be to send an e-mail to support [at] tag1consulting.com.

I hope this helps to explain where things are at the moment. There's a list of specific steps to be taken for a 7.x-1.0 release at #1154982: New 7.x release(s).

_-.’s picture

_-. commented

details are useful.

it's interesting that it was Acquia that initially/partially funded the development.

i don't know tag1consulting. but, if tag1consulting did the original D6 work, and continues to have the expertise to do the D7 work, they should likely see the D7 work through.

but be paid for it.

there are clearly some big players using memcache. apparently, already with D7. as you pointed out, there's (1) no funding, (2) little info about uptake, (2) and little feedback.

imo, unless an alternative to memcache's currently unique (?) utility in D7 appears, this module needs those things to change. the current state of affairs is, at best, an impediment to D7 uptake -- if only for 'high-perf' Drupal.

i always recommend to my end-user clients that they never deploy production systems on top of unfunded, or poorly adopted/supported, mandates. yes, an unknown, 3rd party end-user client can afford to pay a Drupal consulting shop to develop this module. simply not a good business decision.

if one or more of the major Drupal-ecosytem players already using D7+memcache aren't already funding this ... i'll simply refer to your opening paragraph's point.

as an alternative, is a "community bounty" possible? e.g., when the funding bucket's filled this'll get real resources, schedule & a commitment? upside -- it broadens interest, funding and support. downside -- makes it seem like key functionality is being 'held hostage'.

catch’s picture

catch
he/him
Primary language English
commented

Just to be clear the module does get some funding - there is a lot of indirect funding from clients for individual patches and features, and as mentioned Acquia funded the 6.x-1.8 and 6.x-1.9 release. There just hasn't happened to be much recent funding for work on the D7 branch recently (there was some last year when it was initially ported).

Again the main issues with a D7 stable release are we have a number of changes in the 6.x branch that need to be forward ported - that does not make the D7 port 'less stable', it just means the 6.x branch is 'more stable' at the moment. And there has not been that much reporting back (which either means people aren't using it much, or they're not running into problems they can report).

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Active » Fixed

A large number of the missing patches have been ported to D7, a new release has been made and we'll hopefully see a 7.x-1.0 release soon.

What this module needs now is users which test it and report bugs, those and the already known bugs need to be fixed. Nothing that requires major funding efforts IMHO. So I think this issue can be closed as fixed.

Feel free to re-open this if you think otherwise.

catch’s picture

catch
he/him
Primary language English
commented

Yes what was actually need was for Berdir to show up apparently :)

dropbydrop’s picture

dropbydrop commented

+1

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.