As far as mod_*cache is concerned, we should work out the technical definition of what those modules are supposed to be doing and just stick with one direction on trunk. Once that decision is made, folks can veto code on the basis of technical concerns (such as, "that module should be for small items -- big items belong in mod_cache_blah", or "that change causes performance to decrease by 5%, therefore -1").
If the goal needs to change, a new module can be created with that goal as its name (and a new set of config directives to avoid abusing folks who expect their cache to work the same way on the next release). If the current code does not accomplish the technical goal, then it will be fixed on the basis of that goal or removed. If we can't agree on what it is that the modules are supposed to be designed to accomplish, then we should delete them from trunk. If other folks don't like that result, they can bloody well distribute their own cache module. As far as *I* am concerned, changes to the cache code must be correct first and then perform second, and both of those should be proven by actual testing before being committed to trunk. ....Roy
